feat(v2): resume limited threads when usage resets#12686

🟡 Medium settings/settingsSearch.ts:276

Selecting auto-resume-limited-threads navigates to /settings/general#auto-resume-limited-threads without landing on or exposing a control, because that id has no matching anchor and no panel registers it with searchableSetting. Point this result at an existing rendered anchor via targetId, or add the missing anchor/registration.

Fixed in 72499fbdbdf. The row now uses searchableSetting so the Settings search target has a rendered anchor. I exercised the result in the live browser and verified the target exists beside the control.

🟡 Medium threads/UsageLimitRecoveryCard.tsx:37

A failed updateMetadata call is treated as success, so tapping the recovery button clears pending without telling the user that the schedule/cancel change was not persisted. useAtomCommand resolves failures as an AtomCommandResult rather than rejecting, so inspect that result and surface an actionable error in the card, as the web card does.

No longer relevant as of 8170ecdb360c0febf2f74e6f118d9e192d4a92e0

Fixed in 8170ecdb360. The mobile card inspects AtomCommandResult, shows the failure in the card, and releases pending so the user can retry. Scoped mobile typecheck and lint pass.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Ensure a neutralized recovery delivery can be retried. limitRecoveryCommand derives the delivery ID from unchanged recovery data. If a sweep races with thread.snooze, dispatchMessage emits unchanged metadata instead of starting a run, and commitCommand stores an accepted receipt for that command. The snooze branch preserves limitRecovery, so later sweeps reuse the same ID after the wake time. Receipt replay then skips dispatchMessage, and the continuation is lost.

Include a changing component in the delivery ID, or clear limitRecovery when the snooze gate neutralizes the delivery so a later arm creates a new requestId.

✅ Confirmed as addressed by @juliusmarminge

Fixed in 21ff27783f6. A delivery neutralized by a matching active snooze rotates the persisted recovery requestId, so the next sweep gets a fresh delivery identity after waking. The regression exercises the race, then verifies exactly one continuation despite duplicate dispatch.

@juliusmarminge, thanks for the fix. Rotating the recovery request ID after snooze neutralization gives the post-wake sweep a new delivery identity. The regression coverage for duplicate dispatch addresses the reported receipt-replay case.

✅ Review thread resolved.

You are interacting with an AI system.

📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Use the platform-specific settings paths.

On web and desktop, this setting is in Settings → General. On mobile, it is in Settings → Thread behavior.

✅ Confirmed as addressed by @juliusmarminge

Updated the user guide with Settings → General for web/desktop and Settings → Thread behavior for mobile in 21ff27783f6.

🟡 Medium components/ChatView.tsx:10384

When limitRecoveryBanner suppresses visibleThreadError, the timeline still receives topFadeEnabled={false}, so the first message sits flush against the top edge without the normal spacing/fade. hasTimelineTopBanner is based on the non-null visibleThreadError rather than the error actually passed to ThreadErrorBanner; derive the flag from the rendered banner state instead.

No longer relevant as of 92c80bd4a084eddbfd0c23abb56ec8c5377450fe

Fixed in 92c80bd4a084eddbfd0c23abb56ec8c5377450fe. The timeline spacing/fade now derives from timelineThreadError, which is also the value rendered by ThreadErrorBanner. Verified in the live banner flow and scoped web typecheck.

🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win

Do not offer scheduling after the reset time.

canSchedule can remain true after resetAt has passed because it only compares resetAt with stoppedAt. The server accepts and persists this recovery choice because its validation also does not compare resetAt with the current time. The recovery worker later ignores the expired reset, so no continuation occurs, but the UI can still show a misleading scheduled state. Check the current time before showing the action and before persisting limitRecovery.

The current shared scheduler deliberately supports overdue continuations, including after an environment restart. It rejects reset times at or before the stopped run, not valid reset times that have since elapsed. An overdue resume therefore starts immediately rather than being ignored. Snooze is separately rejected after its wake time; the current banner and server both enforce that.

@juliusmarminge, thanks for the clarification. The overdue continuation is intentional and supports recovery after an environment restart. The scheduler correctly validates resetAt against the stopped run, not the current time. My finding incorrectly treated overdue recovery as invalid.

The snooze behavior is distinct and already has the required wake-time validation. I am withdrawing this finding.

🐇

✅ Review thread resolved.

You are interacting with an AI system.

Composable components: this hand-builds a composer-banner action layout inside the stack’s existing ComposerBanner.Actions slot. Compose the recovery notice directly from ComposerBanner.Row, Icon, Content, Actions, and Children so the button and error use the shared slot geometry.

Suggested fix: no self-contained diff; this requires restructuring the stateful notice to compose the banner slots.

^{Posted via Macroscope — UI Consistency}

The stack item is already composed by ComposerBannerStack from ComposerBanner.Root, Row, Icon, Content, Actions, and Children. RecoveryActions is the stateful content of the existing Actions slot, not another banner or row. Composing those slots again inside Actions would nest duplicate banner geometry. Keeping the existing stack item API matches the maintainer’s explicit request to reuse the banner stack and remove redundant description rows.

Import local Effect services as module namespaces at this service boundary, then acquire them through their qualified public tags (for example, yield* ProjectionStore.ProjectionStoreV2). Please update all three imports and the corresponding yield* expressions so the owning module remains visible.

^{Posted via Macroscope — Effect Service Conventions}

Updated recovery dependencies to qualified ServerSettings, ProjectionStore, and ThreadManagement module namespaces, including the slim candidate type in the scheduler layer. Scoped lint and server typecheck pass.

This aliased layer import erases the service module namespace. Please import UsageLimitRecoveryService as a namespace and compose UsageLimitRecoveryService.workerLive (or its conventionally named public layer) at line 299.

^{Posted via Macroscope — Effect Service Conventions}

Updated runtimeLayer to import UsageLimitRecoveryService as a namespace and compose UsageLimitRecoveryService.workerLive.

This module is named as an Effect service, but it exposes only a startup worker layer: there is no Context.Service tag or injectable service implementation, and the private make constructs a sweep function rather than a service. Please rename the module to a worker (for example, UsageLimitRecoveryWorker.ts), rename this constructor to makeSweep, and update the namespace import/consumer in runtimeLayer.ts; alternatively, model it as a canonical tagged service with make and layer.

Suggested fix: no self-contained diff; this requires a file rename and consumer update.

^{Posted via Macroscope — Effect Service Conventions}

Renamed the module to UsageLimitRecoveryWorker.ts and its constructor to makeSweep, retaining the startup worker layer without adding an unnecessary Context.Service tag. Runtime composition and both test consumers use the new filename/namespace. Scoped server typecheck, lint, and scheduler integration tests pass.