fix(server): usage-limit auto-resume retries a continuation refused right after the reset#33737

10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.

• Codex decoded thread snapshot: 108.5 KiB
• Claude decoded thread snapshot: 108.8 KiB

The changes add shared helpers for usage-limit recovery timing and bounded retries after refused continuations. Server recovery and cleanup use derived reset times. Mobile and web views use the same timing for recovery notices and snooze handling.

Changes: Usage-limit recovery

Layer / File(s)	Summary
Shared recovery timing packages/shared/src/orchestrationV2ThreadError.ts, packages/client-runtime/src/state/threadExecution.ts, packages/client-runtime/src/state/threadExecution.test.ts	Shared helpers derive provider reset times, continuation retry times, continuation chains, and notice reset times. The client runtime re-exports the notice helper, and tests cover its timing results.
Continuation retry scheduling apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts, apps/server/src/orchestration-v2/ProjectionStore.test.ts, apps/server/src/orchestration-v2/runtimeLayer.test.ts	Recovery candidates include qualifying refused continuations and can carry forward per-thread auto-resume settings. Tests cover retries after 2, 5, and 15 minutes, snooze deadlines, and the retry limit.
Server recovery state apps/server/src/orchestration-v2/Orchestrator.ts, apps/server/src/storageCleanup.ts, apps/server/src/storageCleanup.test.ts	Orchestration validates and initializes recovery with derived reset times and continuation history. Storage cleanup uses derived notice reset times. Tests cover missing and expired provider resets.
Recovery surfaces apps/mobile/src/features/threads/ThreadDetailScreen.tsx, apps/mobile/src/features/threads/UsageLimitRecoveryCard.tsx, apps/web/src/components/ChatView.tsx, docs/user/thread-sidebar.md	Mobile and web views derive reset times for snooze ownership and recovery notices. The documentation describes retry behavior and conditions that cancel or pause retries.

Estimated code review effort: 4 (Complex) | ~45 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: shivamhwp, t3dotgg

The change adds bounded retries for refused usage-limit continuations, with consistent timing across the server, web and mobile surfaces. No actionable merge-blocking issue was found.

^Failed Failed checks: 1 warning

Check name	Status	Explanation	Resolution
Description check	Warning	The description explains the problem, change, and verification in detail, but it does not include the required maintainer approval comment for this broader behavior change. It also states that the req…	Add a link to the triaged issue or approval discussion and include the maintainer comment that approves the direction and scope. Attach before-and-after screenshots of the web banner and mobile card states required by the template, includin…

^Passed Passed checks: 3 passed

Check name	Status	Explanation
Title check	Passed	The title clearly describes the main change: retrying usage-limit continuations that the provider refuses after the reset.
Linked Issues check	Passed	Active direct target: #33708. Its coding requirements are: (1) a usage-limit continuation refused with no later reset keeps auto-resume armed; (2) retries use bounded backoff; (3) recovery gives up in…
Out of Scope Changes check	Passed	Each changed area supports the retry objective of #33708: - Shared rule and server logic (orchestrationV2ThreadError.ts, ProjectionStore.ts, UsageLimitRecoveryWorker.ts, Orchestrator.ts): implement th…

Full details: Linked Issues check

Explanation

Active direct target: #33708. Its coding requirements are: (1) a usage-limit continuation refused with no later reset keeps auto-resume armed; (2) retries use bounded backoff; (3) recovery gives up into the existing failed state; (4) retries respect cancel, settle, snooze, and archive.

Requirements 1-3 [#33708]: refusedContinuationRetryAt in packages/shared/src/orchestrationV2ThreadError.ts uses 2, 5, and 15 minute steps and returns null after the third step. usageLimitRecoveryResetAt counts consecutive refusals along usageLimitContinuationChain. In ProjectionStore.ts, getLimitRecoveryCandidates adds a refused-continuation branch. It computes the retry time from the refusal count and excludes a thread when a fourth refusal exists (c3.run_id IS NULL). The worker and Orchestrator use the same shared rule, and the worker carries a per-thread auto-resume to the refused run.

Requirement 4 [#33708]: The candidate SQL keeps deleted_at IS NULL, archivedAt IS NULL, settledOverride IS NOT 'settled', and the snooze check. For Cancel, the new carry-over branch requires limitRecovery.autoResume = 1, so a cancelled retry is not a candidate even when global auto-resume is on. Stop uses the same shared rule.

Author-reported evidence: runtimeLayer rows for no-reset, expired-reset, per-thread resume, and manual snooze pass at cbe1b7d96b. The test-only commit 8bfc0a1c0d fails as expected. I did not run these tests. This verdict relies on the diff and the author's report.

Minor uncertainty: the shared helper falls back to requestedAt when completedAt is null, while the SQL falls back to thread updatedAt. This affects only a failed run with no completedAt. This review did not establish that such a run occurs.

The optional 30-60 s grace delay in the issue is a suggestion. The issue states that a delay alone does not fix the defect. Its absence is not a failure.

Full details: Out of Scope Changes check

Explanation

Each changed area supports the retry objective of #33708:

• Shared rule and server logic (orchestrationV2ThreadError.ts, ProjectionStore.ts, UsageLimitRecoveryWorker.ts, Orchestrator.ts): implement the retry, count, give-up, and carry-over behavior.
• Tests (ProjectionStore.test.ts, runtimeLayer.test.ts, storageCleanup.test.ts, threadExecution.test.ts): cover the changed server and client paths.
• Web and mobile UI (ChatView.tsx, ThreadDetailScreen.tsx, UsageLimitRecoveryCard.tsx, threadExecution.ts): show the armed retry time and the Cancel and Wake controls. The issue states that the UI gives no indication of an abandoned recovery. After Cancel, Stop, or give-up, the UI shows the provider reset as before.
• storageCleanup.ts: holds a thread while its retry is armed. This prevents cleanup from removing state that the retry needs.
• docs/user/thread-sidebar.md: documents the retry behavior.

No changed file was shown to be unrelated to #33708. Before/after UI captures are not attached. This limits verification of the UI, not scope.

Full details: Description check

Explanation

The description explains the problem, change, and verification in detail, but it does not include the required maintainer approval comment for this broader behavior change. It also states that the required before-and-after UI screenshots are not attached.

Resolution

Add a link to the triaged issue or approval discussion and include the maintainer comment that approves the direction and scope. Attach before-and-after screenshots of the web banner and mobile card states required by the template, including the armed retry, after Cancel or Stop, and retry-owned snooze states.

Generate docstrings

• Commit to this branch
• Create a new PR

Generate unit tests (beta)

• Commit to this branch
• Create a new PR