chore: sync pnpm-lock.yaml with opencode-local package.json - #208
Closed
MumuTW wants to merge 1 commit into
Closed
Conversation
pnpm-lock.yaml was out of date — @types/node specifier was ^22.12.0 in the lockfile but ^24.6.0 in package.json, causing CI to fail with ERR_PNPM_OUTDATED_LOCKFILE on every PR.
MrFadiAi
approved these changes
Mar 7, 2026
MrFadiAi
left a comment
MrFadiAi
left a comment
There was a problem hiding this comment.
This PR is necessary to unblock CI for all other PRs. The lockfile is out of sync with opencode-local/package.json (@types/node version mismatch). Merging this should be prioritized despite the CI failure (which is caused by the very issue this PR fixes).
Collaborator
|
This is resolved by CI now,
|
Chadonillo
added a commit
to MareAnalytica/paperclip
that referenced
this pull request
Jun 3, 2026
…ion core (1/2) (#129) * feat(ELI-952): Contract C cross-run unresponsive-hang breaker decision core Pure decision core for the cross-run repeated-hang circuit breaker (Contract C of the ELI-947 silence-watchdog remediation tree). Contract A (ELI-950) types a hung invocation as `adapter_no_output_timeout`; Contract B (ELI-951) advances the fallback chain when that hang lands on a non-primary hop. Neither bounds the hang *across runs*, so a fresh run re-picking the same (agent, provider) pair hangs again — the detect -> re-queue -> hang loop. `decideUnresponsiveRecovery` takes the consecutive cross-run hang count for an (issue, provider) pair plus whether a healthy alternative exists and returns failover / bounded retry-same / escalate, enforcing the spec §5 invariants: healthy alternative always wins; retry-same only within `maxUnresponsiveRetriesPerProvider`; the N+1th identical hang escalates (opens a typed operator recovery action) and NEVER re-routes to the hung pair. `buildProviderHealthAuditEvent` emits the blueprint §4 audit shape (no credential material). Re-derived from the eli-board `eli-board.provider-health.v1` blueprint (ELI-961, PR paperclipai#208), not imported — the runtime owns its enforcement copy. No wiring into the recovery service yet (next increment): the count is sourced from `issue_recovery_actions.attemptCount` (whose active-fingerprint unique index keeps it from resetting on re-pickup) and the skip side reuses the ELI-855 cooldown store. 10 unit tests cover all invariants incl. the N+1th-hang acceptance. Co-Authored-By: Paperclip <noreply@paperclip.ing> * feat(ELI-952): Contract C provider-health policy surface + cross-run unresponsive cooldown demerit Wire the cross-run repeated-hang circuit breaker into the runtime (ELI-947 Contract C / spec eli-board.provider-health.v1 §3.2/§3.4/§3.5): - provider-fallback-policy: parse + validate the optional `providerFallback.providerHealth` block (invocation timeouts, cooldownMs, recovery.maxUnresponsiveRetriesPerProvider) with the spec's disabled default (omitted block => pre-ELI-961 behavior) and opt-in partial defaults; add `resolveProviderHealthPolicy` / `resolveInvocationTimeoutMs`. - provider-unresponsive-breaker: add `resolveProviderUnresponsiveRecovery` composer — derive the healthy alternative from the live fallback chain + ELI-855/856 cooldown set, decide failover/retry_same/escalate, and build the §4 audit event in one pure call. - heartbeat: on a no-output adapter hang (provider_unresponsive) on ANY adapter — including the primary, which the Contract-B hop path never reaches — record a typed `provider_unresponsive` cooldown demerit (window = providerHealth.cooldownMs) so the existing root-run skip (pickRootRunProviderSelection) starts the next run on a healthy provider instead of re-selecting the hung one. Emit the breaker decision + §4 audit event onto the run trail. Fully config-gated (cooldownMs=0 => no-op). - provider-account-cooldown: add the `provider_unresponsive` cooldown source. Tests: composer failover/escalate/retry invariants incl. the N+1th-hang acceptance; providerHealth parse/validate/resolve incl. disabled default, partial opt-in defaults, per-provider timeout overrides, range + slug validation. Precise N-bound escalate (open a typed operator recovery action via the cross-run issue_recovery_actions.attemptCount) is the recovery-service follow-up per spec §7#1. Co-Authored-By: Paperclip <noreply@paperclip.ing> --------- Co-authored-by: Paperclip Platform Engineer <noreply@paperclip.ing>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
CI is currently broken on
master— every PR fails atpnpm install --frozen-lockfile:This PR runs
pnpm installto sync the lockfile. 9 lines changed.