You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(server): usage-limit auto-resume no longer arms subagents of archived or deleted parents - #30363
#27951 stopped the usage-limit recovery sweep from freshly arming a subagent whose parent is settled. The same query still arms a subagent whose parent is archived or deleted. With Resume after usage limits on (or snooze), that child is armed and resumed at its reset. It runs a full turn on the user's quota for a task whose parent the user has put away, and its completion cannot wake the parent: delivery to an archived or deleted parent is disposed. A deleted parent never comes back to read the result. An archived one keeps it on the parent's task, but nobody asked for the turn that produced it.
Agent-started subagent threads cannot take messages, so nothing but this sweep drives such a child. The query already treats an archived thread like a settled one when the thread itself is the candidate. Since #27951 it checks the parent's settled state too, but not its archived or deleted state.
Change
In getLimitRecoveryCandidates, the parent check that #27951 added now also matches a parent with archivedAt set or a non-null deleted_at, not just settledOverride = 'settled'. It covers both arm branches, auto-resume and snooze. The parent is still found by its primary key, only for rows that passed the usage-limit pre-filter.
As in #27951, the resume branch is unchanged, so a recovery armed before the parent was put away still resumes. Unarchiving the parent emits a thread.* event, which makes the sweep due again and offers the child once more, within the same limits as any fresh arm (auto-resume only within 24 hours of the reset, snooze only while the reset is still ahead).
Scope and approval
This is a small, focused fix for an obvious bug, so it needs no prior issue. It is one SQL condition plus #27951's existing test extended from two parent states to four. The harm differs from #27951's: there the resumed child reopened a settled parent, while here the wake is disposed and the cost is the quota spent on a turn for put-away work. The rule is the one the query already applies to the thread itself.
Related open work: #30175 cancels already-armed resumes of settled parents' children in Orchestrator.dispatchMessage. It does not touch this query, so the two do not conflict. If both merge, an already-armed resume of an archived or deleted parent's child still runs at its reset; that is a follow-up, kept out of this PR. #20072 cascades archive and delete to subagent descendants. It conflicts with main, does not touch this query, and would not cover children of parents archived before it lands.
Verification
apps/server/src/orchestration-v2/ProjectionStore.test.ts: the #27951 case, renamed does not freshly arm limit recovery for a subagent of a put-away parent, now builds four parent/child pairs (settled, archived, deleted, open parent) and checks that only the open parent's child is armed, under both autoResume and snooze.
On main with only the test commit (ce48080), from apps/server, vp test run src/orchestration-v2/ProjectionStore.test.ts -t "put-away parent":
× does not freshly arm limit recovery for a subagent of a put-away parent
AssertionError: only the child of the open parent is armed ({"now":"1970-01-01T00:00:00.000Z","autoResume":true,"snooze":false}): expected [ …(3) ] to deeply equal [ Array(1) ]
+ "thread:settled-parent-limit:archived:child",
+ "thread:settled-parent-limit:deleted:child",
Tests 1 failed | 50 skipped (51)
The settled child is already excluded on main, so the test fails only on the two new parent states.
With the fix, from apps/server:
vp test run src/orchestration-v2/ProjectionStore.test.ts src/orchestration-v2/UsageLimitRecoveryWorker.test.ts: 56/56 pass.
vp run check:changed from the repo root: format, lint, knip, graphql, typecheck (3 packages) and tests beside the change all pass.
What I could not check: a runtime transcript. Reaching this path on a running server needs a provider to hit a real usage limit with a reset time, which cannot be triggered on demand. The test drives the real projection store and its candidate query, which is the only code this PR changes. There is no visible surface, so there are no captures.
Bug: usage-limit auto-resume arms subagents of archived or deleted parents
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.
…ived or deleted parents
pingdotgg#27951 stopped the usage-limit recovery sweep from freshly arming a
subagent whose parent is settled. The same query still armed a subagent
whose parent was archived or deleted, so turning on Resume after usage
limits (or snooze) resumed abandoned children at their reset and spent
the user's quota on a turn whose completion cannot wake the parent:
delivery to an archived or deleted parent is disposed.
The parent check in getLimitRecoveryCandidates now treats an archived or
deleted parent the same as a settled one. The resume branch is unchanged,
as in pingdotgg#27951.
Bug: usage-limit auto-resume arms subagents of archived or deleted parents
No actionable comments were generated in the recent review.
Walkthrough
Limit-recovery candidate selection now excludes subagents whose parent is settled, archived, or deleted. Tests cover those parent states alongside active parents, including a settled-parent child with recovery already armed.
Changes: Limit recovery
Layer / File(s)
Summary
Parent-state filtering and test coverage apps/server/src/orchestration-v2/ProjectionStore.ts, apps/server/src/orchestration-v2/ProjectionStore.test.ts
The limit-recovery query excludes subagents with settled, archived, or deleted parents. The test covers these states and active parents, and retains coverage for an already-armed child of a settled parent.
Children of put-away parents are excluded from fresh recovery arms; already-armed recoveries remain unchanged. No material merge-blocking issue was identified.
Pre-merge checks: 4
Check name
Status
Explanation
Title check
The title clearly and concisely describes the main change: preventing usage-limit recovery from freshly arming subagents whose parents are archived or deleted.
Linked Issues check
Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check
Check skipped because no linked issues were found for this pull request.
Description check
The pull request description includes all required sections. It clearly explains the problem, the code change, scope and approval rationale, focused verification results, failed baseline behavior, lim…
Full details: Description check
Explanation
The pull request description includes all required sections. It clearly explains the problem, the code change, scope and approval rationale, focused verification results, failed baseline behavior, limitations, and the agent and harness used.
Finishing Touches
Generate unit tests (beta)
Create a new PR
Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
CodeRabbit Verify
Run CodeRabbit Verify to test the changes in this pull request.
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 1 remain after this review.
Partial verification of fa3f5c029e51a6c31f269ed8b272ee4002cf9068 on Linux. This is not a runtime verification of the recovery fix.
Installed and ran github/main (7c22e24e3f) in a separate worktree, stopped its captured server process, then installed and ran the exact PR head. Only one dev server ran at a time.
Drove the real web app using repository Playwright and /usr/bin/google-chrome. Added a project pointing at a real git checkout through the app. No mocks, fixtures, demo data, or database writes.
On both versions, real Codex gpt-6.1-sol parent turns and T3-delegated child turns completed through the local proxy.
On the PR, archived and unarchived the parent through the UI, then sent another real Codex message. It returned RESTORED_PARENT_OK. Both recovery preferences persisted through a page reload.
Ran the existing projection-store and recovery-worker tests through blacksmith-check: 56 tests passed across two files. No source changes or pushes.
The original bug was not reproduced on main, and fresh recovery filtering for archived/deleted parents was not exercised on the PR. Neither environment produced a real usage_limit failure with resetAt. The first PR turn encountered a proxy 429, but it was a recoverable transport_error (responseStreamDisconnected) without a reset timestamp and then completed. That does not prove usage-limit recovery.
Consequently, auto-resume and snooze fresh-arm exclusion, re-eligibility after unarchive, and already-armed reset-time continuation remain unverified in the running app. Exercising them requires a genuine provider usage-limit failure with an exhausted account window and reset time. I did not fabricate that state or intentionally exhaust quota.
Native desktop, iOS/Android, other providers, and remote/relay connections were not exercised.
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
size:XS0-9 changed lines (additions + deletions).vouch:unvouchedPR author is not yet trusted in the VOUCHED list.
2 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.
github-actions
Bot
added
vouch:unvouched
Problem
#27951 stopped the usage-limit recovery sweep from freshly arming a subagent whose parent is settled. The same query still arms a subagent whose parent is archived or deleted. With Resume after usage limits on (or snooze), that child is armed and resumed at its reset. It runs a full turn on the user's quota for a task whose parent the user has put away, and its completion cannot wake the parent: delivery to an archived or deleted parent is disposed. A deleted parent never comes back to read the result. An archived one keeps it on the parent's task, but nobody asked for the turn that produced it.
Agent-started subagent threads cannot take messages, so nothing but this sweep drives such a child. The query already treats an archived thread like a settled one when the thread itself is the candidate. Since #27951 it checks the parent's settled state too, but not its archived or deleted state.
Change
In
getLimitRecoveryCandidates, the parent check that #27951 added now also matches a parent witharchivedAtset or a non-nulldeleted_at, not justsettledOverride = 'settled'. It covers both arm branches, auto-resume and snooze. The parent is still found by its primary key, only for rows that passed the usage-limit pre-filter.As in #27951, the resume branch is unchanged, so a recovery armed before the parent was put away still resumes. Unarchiving the parent emits a
thread.*event, which makes the sweep due again and offers the child once more, within the same limits as any fresh arm (auto-resume only within 24 hours of the reset, snooze only while the reset is still ahead).Scope and approval
This is a small, focused fix for an obvious bug, so it needs no prior issue. It is one SQL condition plus #27951's existing test extended from two parent states to four. The harm differs from #27951's: there the resumed child reopened a settled parent, while here the wake is disposed and the cost is the quota spent on a turn for put-away work. The rule is the one the query already applies to the thread itself.
Related open work: #30175 cancels already-armed resumes of settled parents' children in
Orchestrator.dispatchMessage. It does not touch this query, so the two do not conflict. If both merge, an already-armed resume of an archived or deleted parent's child still runs at its reset; that is a follow-up, kept out of this PR. #20072 cascades archive and delete to subagent descendants. It conflicts withmain, does not touch this query, and would not cover children of parents archived before it lands.Verification
apps/server/src/orchestration-v2/ProjectionStore.test.ts: the #27951 case, renameddoes not freshly arm limit recovery for a subagent of a put-away parent, now builds four parent/child pairs (settled, archived, deleted, open parent) and checks that only the open parent's child is armed, under bothautoResumeand snooze.On
mainwith only the test commit (ce48080), fromapps/server,vp test run src/orchestration-v2/ProjectionStore.test.ts -t "put-away parent":The settled child is already excluded on
main, so the test fails only on the two new parent states.With the fix, from
apps/server:vp test run src/orchestration-v2/ProjectionStore.test.ts src/orchestration-v2/UsageLimitRecoveryWorker.test.ts: 56/56 pass.vp run check:changedfrom the repo root: format, lint, knip, graphql, typecheck (3 packages) and tests beside the change all pass.What I could not check: a runtime transcript. Reaching this path on a running server needs a provider to hit a real usage limit with a reset time, which cannot be triggered on demand. The test drives the real projection store and its candidate query, which is the only code this PR changes. There is no visible surface, so there are no captures.
Bug: usage-limit auto-resume arms subagents of archived or deleted parents
This was written with Claude Opus 5.5 in Claude Code, driven from T3 Code.