[Bug]: Enabling usage-limit auto-resume unexpectedly restarts previously settled threads #28305

Activity

1. laclcia

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 31, 2026
2. fixfon commented on Oct 31, 2026

   

   fixfon

   on Oct 31, 2026

   Contributor

   More actions

   This looks like the same bug as #27944, which has an open fix in #27951. On current main, limitRecoveryCommand in apps/server/src/orchestration-v2/UsageLimitRecoveryWorker.ts already skips a thread whose own settledOverride is settled, and it skips resets more than 24h overdue. So a settled thread most likely restarts when one of its delegated children is armed and the child's completion wakes the parent. Did the threads that came back have delegated children that hit the usage limit? If so, this can be closed as a duplicate of #27944.
3. laclcia commented on Nov 5, 2026

   

   laclcia

   on Nov 5, 2026

   Author

   More actions

   i believe most of them had childrens that failed yes. i did not make the link it was childrens. i see the PR was pulled in and i just now had the same problem happen again on t3 nightly t3@0.1.8-nightly.20261105.4234. not shure if that PR is part of that build but if it was then it did not fix the bug for me.
4. fixfon commented on Nov 5, 2026

   

   fixfon

   on Nov 5, 2026

   Contributor

   More actions

   Thanks — that helps. #27951 merged as 95414cf (2026-11-03), and t3@0.1.8-nightly.20261105.4234 is 8b570d2, which includes that commit.

   That fix only blocks freshly arming a subagent of an already-settled parent. A child that already had a limit-recovery arm can still resume at its reset and wake the parent.

   For the latest incident, were those children already armed / waiting on a usage-limit reset before the parents were settled, or did they only arm after you turned auto-resume on? Parent + child thread ids (or the resume log lines) would pin which path this is.
5. laclcia commented on Nov 6, 2026

   

   laclcia

   on Nov 6, 2026

   Author

   More actions

   Posted by 6.1 Sol on behalf of @laclcia

   I am the AI agent assisting @laclcia. The findings below come from a read-only audit of the local T3 instance involved in this report. The usage observation is @laclcia's.

   The retained event database shows nine child runs with explicit node:delegated-task:limit-resume IDs across five parents on t3@0.1.8-nightly.20261105.4234. They started on November 5 between 20:25:42.890Z and 20:26:04.072Z, shortly before @laclcia's 20:39:19Z comment. Six failed and three completed.

   Three child completions were immediately followed by parent thread.unsettled events. These exact parent/child pairs may help trace the path. All times below are UTC on November 5.

   Parent 5187f57e-7ce7-434d-b325-bc1e2938e544

   • Child: thread:delegated-task:command%3Amcp%3A4393c42e-3784-4e77-b9cc-9d0b397344ec%3Adelegate-task%3Amusic-build-debug-r1
   • Child completed: 20:27:04.089Z
   • Parent unsettled: 20:27:05.488Z

   Parent 5e841ffa-6094-41ee-b5b1-f1678665db55

   • Child: thread:delegated-task:command%3Amcp%3A6049e250-b38f-4fca-88b1-0c980a7fd7fd%3Adelegate-task%3Aflux1-cold-performance-attribution-sol-20261019-r10
   • Child completed: 20:27:40.412Z
   • Parent unsettled: 20:27:40.769Z

   Parent 870e6784-43dd-4fda-867d-206c0ad19716

   • Child: thread:delegated-task:command%3Amcp%3Adf8e1a78-c7c9-4a0c-8ca8-725072d4350b%3Adelegate-task%3Atiny-private-ui-backend-20261016-r1
   • Child completed: 20:29:31.078Z
   • Parent unsettled: 20:29:32.327Z

   This timing is consistent with your suggestion that child completion woke the parents. However, the retained records do not establish whether the triggering recovery arms existed before the parents were settled or were created when auto-resume was enabled. The limit-arm: updates verified in the audit occurred afterward, between 20:29:12Z and 20:30:07Z, targeting the next reset on November 8 at 00:42Z. Those later updates do not explain what triggered the initial burst.

   @laclcia reports that many previously settled threads resumed without a request to continue, about 2% of the weekly allowance disappeared within seconds, and the usage limit was reached again. The quota figure is the user's observation; the database audit did not independently verify consumption.
6. fixfon commented on Nov 7, 2026

   

   fixfon

   on Nov 7, 2026

   Contributor

   More actions

   Thanks for the audit. An already-armed child can still resume at reset and wake a settled parent on completion; #27951 only blocks fresh arms. On current main, UsageLimitRecoveryWorker.ts:limitRecoveryCommand resumes the child, and its completion is delivered through Orchestrator.ts:finalizeAppOwnedSubagentTask to dispatchMessage, which emits thread.unsettled without checking the parent's settled state. The recorded arm updates do not explain the initial burst, and the ~2% quota observation is unverified. #28360 also disarms the settled thread's own recovery on the server, but not an armed child of a settled parent; #30175 targets that path.