Synced from GitHub
fix(server): a parent stays Working while a resumed child waits on its own subagent#30469
Problem
When a parent sends a follow-up to a delegated child that has already finished, and the child delegates its own subagent in that follow-up and ends its turn, the parent's follow-up task resolves at once with the child's interim reply. The parent leaves Working while the grandchild and then the child's resumed run are still working (Lineage still says 1 running), and the child's final answer never reaches the parent.
Reproduced on main (aee76a8b47) in the web app with a Codex parent, child and grandchild, following the reporter's steps: the follow-up resolved with CHILD_WAITING while the grandchild ran, the parent replied PARENT_SAW CHILD_WAITING, and the child's CHILD_DONE from its resumed run was never delivered. A Claude parent shows the same thing. A new child that delegates a grandchild stays in Working, as the reporter's control said.
Change
finalizeAppOwnedSubagent only held the original delegated task open until the child's work settled. A follow-up task resolved as soon as the one run it was bound to ended. Now every task is held the same way: it resolves once delegatedTaskProgress over the runs it owns reaches result_available, using the latest of those runs as its result.
The runs a task owns come from one helper, delegatedRunOwners in provider-core:
- A bound run belongs to its task.
- A delegated-completion wake belongs to the task that owns the run whose subagents woke it (
delegatedCompletion.parentRunId). - A restart continuation belongs to the owner of the run it continues.
- Any other unbound run, such as a user turn or a provider notification wake, belongs to the task whose bound run most recently started before it. A queued run that has not started owns nothing else.
Every reader of task ownership uses that helper: finalization, the follow-up join check in recordSubagentFollowup (a wake or user turn now joins the task that owns it while that task is open, instead of opening a second follow-up), MCP task_status (result transfer id, pending approval), t3_thread_read acknowledgement, DelegatedTaskQuestionReactor and RestartContinuation. mayStartSubagentFollowup is unchanged.
Scope and approval
Fixes pingdotgg/t3code#30395
Triaged via the automated issue flow.
Verification
Focused tests, each failing on main (or on the commit before its fix) and passing at the head:
DelegatedCompletionDelivery.test.ts›subagent follow-ups›holds a follow-up open $scenario: three cases, the reporter's flow, a completion wake that runs ahead of a later queued follow-up, and a later follow-up that starts and finishes first. On main:follow-up task finalized while the child's grandchild is still running: expected 'CHILD_WAITING' to equal null.DelegatedCompletionDelivery.test.ts›delivers a %s that starts while only a held follow-up is open(provider wake, user turn): the answer reaches the parent exactly once.OrchestratorMcpService.test.ts›credits a follow-up with the result of the wake run that joined itandreports an approval on the wake run that joined an open follow-up.SubagentProjection.test.ts›credits a restarted completion wake to the task whose run caused the wake.vp run check:changedpasses: format, lint, knip, typecheck (26 packages), tests (8 files). The related orchestration-v2 and MCP suites (follow-ups, delegated completion, restart continuation, thread stop, background work, questions, task status) pass.
Runtime, real web app and real Codex provider (gpt-6.1-sol), fresh database per side, same driver. Before is main aee76a8b47; after is af83329631, and the driver was rerun at the final fix commit e09a011f6c with the same result (transcript below). The commits after af83329631 change ownership only for held queues, approvals, overlapping follow-ups and restarts, none of which this flow exercises. Chrome, 1280×800 CSS viewport, DPR 2, light theme, no emulation. Thread ids, timers, durations and the model's wording differ between runs by nature. The diff images are lit by those as well, so they do not isolate the change.
Timeline of the recordings (UTC):
| Milestone | Before | After |
|---|---|---|
Child ends its follow-up turn with CHILD_WAITING | 22:35:21 | 22:39:18 |
| Grandchild completion resumes the child | 22:35:56 | 22:39:51 |
Resumed child finishes CHILD_DONE | 22:37:30 | 22:41:31 |
| Parent's result | CHILD_WAITING at 22:35:24, before the grandchild finished | CHILD_DONE at 22:41:34 |
Recordings, one uninterrupted run each (follow-up sent → child ends CHILD_WAITING → grandchild finishes → child resumes → child ends CHILD_DONE), 960 wide at 4 fps, untrimmed:
| Before: main aee76a8b47 | After: fix af83329631 |
|---|---|
Stills, 1280×800, light theme:
| Row | Before (aee76a8b47) | After (af83329631) | Diff0 | DiffT (2% fuzz) |
|---|---|---|---|---|
| R2: grandchild running, child's follow-up turn already ended | ||||
| R4: final state |
What else changed, all following from the follow-up staying open: in R2 the parent moves into the Working shelf with a "Waiting" pill, its task card is Running rather than finished, a Waiting footer with Open/Stop replaces the early completion and reply, and Lineage reads "1 running". In R4 the task, notification and parent reply read CHILD_DONE instead of CHILD_WAITING, and the durations are longer. The remaining differences (thread ids, timestamps, timers, the model's wording and where history lands) vary from run to run.
Runtime transcripts (runs and tasks from the dev database)
| 1 | # main aee76a8b47, Codex gpt-6.1-sol, same driver.sh, fresh DB |
| 2 | 22:06:35.900 | parent | run 1 completed (22:06:35-22:06:47) unbound |
| 3 | 22:06:45.762 | parent | task delegate completed result=CHILD_READY completedAt=22:06:49 |
| 4 | 22:06:45.766 | child | run 1 completed (22:06:45-22:06:49) unbound |
| 5 | 22:06:49.851 | parent | run 2 completed (22:06:49-22:06:58) unbound |
| 6 | 22:07:00.703 | parent | run 3 completed (22:07:00-22:07:14) unbound |
| 7 | 22:07:08.822 | child | run 2 completed (22:07:08-22:07:21) bound to task [delegatedCompletion] |
| 8 | 22:07:08.822 | parent | task follow-up completed result=CHILD_WAITING completedAt=22:07:21 |
| 9 | 22:07:19.733 | child | task delegate completed result=GRANDCHILD_DONE completedAt=22:07:56 |
| 10 | 22:07:19.736 | grandchild | run 1 completed (22:07:19-22:07:55) unbound |
| 11 | 22:07:22.065 | parent | run 4 completed (22:07:22-22:07:24) unbound |
| 12 | 22:07:56.475 | child | run 3 completed (22:07:56-22:09:30) unbound |
| 13 | ## parent's last messages (checked 22:09:53, 20s after the child's final run ended) |
| 14 | assistant: I’ll send the follow-up once to the same child and end this turn immediately. |
| 15 | assistant: Sent to <t3-thread://v2/5386a5e4-7665-4450-a383-269f51e7a2ab/thread:delegated-task:command%3Amcp%3A86b36be1-58a6-477c-9e |
| 16 | assistant: PARENT_SAW CHILD_WAITING |
| 1 | # final head e09a011f6c, Codex gpt-6.1-sol, same driver.sh, fresh DB |
| 2 | ## sample at 23:31:33 (grandchild running, child's follow-up run ended): |
| 3 | 23:31:20.508 | parent | task follow-up running result=<none> completedAt=- |
| 4 | 23:31:29.284 | grandchild | run 1 running (23:31:29-…) unbound |
| 5 | ## final |
| 6 | 23:30:44.312 | parent | run 1 completed (23:30:44-23:30:54) unbound |
| 7 | 23:30:53.349 | parent | task delegate completed result=CHILD_READY completedAt=23:30:57 |
| 8 | 23:30:53.357 | child | run 1 completed (23:30:53-23:30:56) unbound |
| 9 | 23:30:57.503 | parent | run 2 completed (23:30:57-23:31:11) unbound |
| 10 | 23:30:58.970 | parent | run 3 completed (23:30:58-23:31:23) unbound |
| 11 | 23:31:20.508 | child | run 2 completed (23:31:20-23:31:31) bound to task [delegatedCompletion] |
| 12 | 23:31:20.508 | parent | task follow-up completed result=CHILD_DONE completedAt=23:33:48 |
| 13 | 23:31:29.279 | child | task delegate completed result=GRANDCHILD_DONE completedAt=23:32:12 |
| 14 | 23:31:29.284 | grandchild | run 1 completed (23:31:29-23:32:12) unbound |
| 15 | 23:32:13.152 | child | run 3 completed (23:32:13-23:33:47) unbound |
| 16 | 23:33:48.894 | parent | run 4 completed (23:33:48-23:33:51) unbound |
| 17 | ## parent's last messages |
| 18 | assistant: I’ll send the follow-up once to the same child, then end this turn immediately. |
| 19 | assistant: Sent. |
| 20 | assistant: PARENT_SAW CHILD_DONE |
| 21 | ## subagent_result transfers to the parent: 2 |
Driver and transcript scripts (scratch, not committed)
bash
| 1 | #!/bin/bash |
| 2 | # Reproduces pingdotgg/t3code#30395 against a running dev server (started with T3CODE_DEV_SEED=0). |
| 3 | # usage: driver.sh <checkout> <scratch-project-dir> <provider> <model> |
| 4 | # 1. parent delegates a trivial async child and both finish |
| 5 | # 2. parent t3_thread_sends a follow-up to the SAME completed child: the child delegates a grandchild |
| 6 | # (sleep 30), ends its turn with CHILD_WAITING, and on resume runs sleep 90 then replies CHILD_DONE |
| 7 | # Prints the parent thread id. Read the outcome with transcript.sh. |
| 8 | set -euo pipefail |
| 9 | CHECKOUT=$1; PROJ=$2; PROVIDER=$3; MODEL=$4 |
| 10 | B=$CHECKOUT/.t3; DB=$B/userdata/statev2.sqlite |
| 11 | cd "$CHECKOUT/apps/server" |
| 12 | t3() { node src/bin.ts "$@" --base-dir "$B"; } |
| 13 | settled() { [ "$(sqlite3 -readonly "$DB" "select count(*) from orchestration_v2_projection_runs where status not in ('completed','failed','cancelled','interrupted','rolled_back')")" = 0 ]; } |
| 14 | |
| 15 | if [ ! -d "$PROJ/.git" ]; then |
| 16 | mkdir -p "$PROJ" && git -C "$PROJ" init -q && echo scratch > "$PROJ/README.md" |
| 17 | git -C "$PROJ" add . && git -C "$PROJ" -c user.email=repro@example.com -c user.name=repro commit -qm init |
| 18 | fi |
| 19 | t3 project add "$PROJ" >/dev/null 2>&1 || true |
| 20 | |
| 21 | PARENT=$(t3 thread start --provider "$PROVIDER" --model "$MODEL" --title "P30395 $PROVIDER parent" --json "$PROJ" \ |
| 22 | 'Use delegate_task (mode async) to start one child with this task: "Reply CHILD_READY and nothing else. Do not run commands or edit files." After dispatch, end your turn; do not poll. When its completion wakes you, reply PARENT_SAW_CHILD followed by the child thread id, and end your turn.' \ |
| 23 | | python3 -c 'import json,sys;print(json.load(sys.stdin)["threadId"])') |
| 24 | sleep 3; until settled; do sleep 2; done |
| 25 | CHILD=$(sqlite3 -readonly "$DB" "select json_extract(payload_json,'\$.childThreadId') from orchestration_v2_projection_subagents where thread_id='$PARENT' limit 1") |
| 26 | t3 thread send "$PARENT" "Call t3_thread_send exactly once (mode auto, clientRequestId p30395-followup-$(date +%s)) to the SAME completed child thread $CHILD with this message: \"Use delegate_task for one local async grandchild. Grandchild runs sleep 30 once in the foreground, then replies GRANDCHILD_DONE. After dispatch reply CHILD_WAITING and end your turn; no polling. When completion resumes you, run sleep 90 in the foreground then reply CHILD_DONE. Do not edit files.\" After the send, end your turn immediately. Do not wait, poll, or call task_status. When the follow-up's completion wakes you, reply PARENT_SAW followed by the result." >/dev/null |
| 27 | echo "$PARENT" |
bash
| 1 | #!/bin/bash |
| 2 | # usage: transcript.sh <db> <parent-thread-id> ; runs and tasks of a parent and its descendants, in time order |
| 3 | DB=$1; P=$2 |
| 4 | sqlite3 -readonly -separator ' | ' "$DB" " |
| 5 | with recursive d(id,depth) as (select '$P',0 union all select t.thread_id,d.depth+1 from orchestration_v2_projection_threads t join d on json_extract(t.payload_json,'$.lineage.parentThreadId')=d.id) |
| 6 | select * from ( |
| 7 | select substr(r.requested_at,12,12) as at, case d.depth when 0 then 'parent' when 1 then 'child' else 'grandchild' end as who, |
| 8 | 'run '||r.ordinal||' '||r.status||' ('||substr(r.requested_at,12,8)||'-'||coalesce(substr(r.completed_at,12,8),'…')||')'|| |
| 9 | case when json_extract(r.payload_json,'$.delegatedTaskId') is null then ' unbound' else ' bound to task' end || |
| 10 | case when d.depth>0 and json_extract(r.payload_json,'$.delegatedCompletion') is not null then ' [delegatedCompletion]' else '' end |
| 11 | from d join orchestration_v2_projection_runs r on r.thread_id=d.id |
| 12 | union all |
| 13 | select substr(json_extract(s.payload_json,'$.startedAt'),12,12), case d.depth when 0 then 'parent' else 'child' end, |
| 14 | 'task '||case when s.subagent_id like '%thread-send%' then 'follow-up' else 'delegate' end||' '||json_extract(s.payload_json,'$.status')||' result='||substr(coalesce(json_extract(s.payload_json,'$.result'),'<none>'),1,30)||' completedAt='||coalesce(substr(json_extract(s.payload_json,'$.completedAt'),12,8),'-') |
| 15 | from d join orchestration_v2_projection_subagents s on s.thread_id=d.id |
| 16 | ) order by at" |
Not checked live: mobile (it uses the same shared Working logic and server state; not run on a device), remote linked-environment delegation (separate path, unchanged), and the failure, cancel, interrupt and held-restart variants, which are covered only by the tests above and the existing suites. In the before recording, the composer briefly covers the parent's reply around 01:25; the R4 stills show that state.
Claude Opus 5.5 (Claude Code) as issue lead, with Claude Opus 5.5 and GPT-6.1-Sol (Codex) step agents, in T3 Code.
🤖 Generated with Claude Code
Checks
23 successful · 17 skipped
Added 7 commits
- fix(server): hold a subagent follow-up open until the child's work settles06e52c0
- test(server): reproduce #30395, follow-up task finalizes before the child's subagent settles1d5d556
- fix(server): a restarted subagent run stays with the task that owned its source49fe1ce
- Merge remote-tracking branch 'origin/main' into fix/issue-303956befbc7
- fix(server): a subagent's unbound runs belong to the task that last startedaf83329
- fix(server): a subagent's wake joins only the open task that owns itce24fd2
- fix(server): a delegated-completion wake belongs to the task whose run caused ite09a011
Synced from GitHub
Approvability
Verdict: Approved at 49fe1ce
Macroscope's review found this PR approvable — Tracks which delegated task owns resumed and follow-up runs so parents remain working while child work is pending and receive the appropriate result. Existing completion safeguards remain intact, with no new permissions or destructive operations introduced.
You can add or adjust custom eligibility rules. Learn more.
Synced from GitHub
Thread transfer impact
✅ Thread transfer remains within every enforced ceiling.
| Provider | Metric | Main baseline | This PR | Impact | PR ceiling | |
|---|---|---|---|---|---|---|
| Codex | Total thread wire | 5.0 KiB | 5.0 KiB | 0 B (0.0%) | 6.8 KiB | ✅ |
| Codex | Thread snapshot wire | 3.8 KiB | 3.8 KiB | 0 B (0.0%) | 4.9 KiB | ✅ |
| Codex | Live turn WebSocket wire | 1.2 KiB | 1.2 KiB | 0 B (0.0%) | 2.0 KiB | ✅ |
| Codex | Live turn WebSocket decoded | 21.5 KiB | 21.5 KiB | 0 B (0.0%) | 24.4 KiB | ✅ |
| Codex | Live turn messages | 1 | 1 | 0 (0.0%) | 8 | ✅ |
| Claude | Total thread wire | 5.0 KiB | 5.0 KiB | 0 B (0.0%) | 6.8 KiB | ✅ |
| Claude | Thread snapshot wire | 3.8 KiB | 3.8 KiB | 0 B (0.0%) | 4.9 KiB | ✅ |
| Claude | Live turn WebSocket wire | 1.2 KiB | 1.2 KiB | 0 B (0.0%) | 2.0 KiB | ✅ |
| Claude | Live turn WebSocket decoded | 21.9 KiB | 21.9 KiB | 0 B (0.0%) | 24.4 KiB | ✅ |
| Claude | Live turn messages | 1 | 1 | 0 (0.0%) | 8 | ✅ |
Baseline: 8bc344b · PR result: 49fe1ce · Source CI: success
Scenario and decoded snapshot size
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
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed.
Synced from GitHub
No actionable comments were generated in the recent review.
Walkthrough
The change assigns child runs to delegated tasks using explicit task IDs, wake and restart causality, and task start order. Orchestration and MCP task views use that ownership for follow-up finalization, result delivery, approvals, and status. Tests cover nested delegated work, wakes, restart continuations, and approval reporting.
Changes: Delegated Task Ownership and Results
Layer / File(s) Summary Resolve delegated run ownership
packages/provider-core/src/server/subagentProjection.ts,apps/server/src/orchestration-v2/SubagentProjection.test.tsNew helpers map child runs to delegated task owners and select runs by owner. Tests cover ownership across completion wakes, restart continuations, and later user turns. Resolve continuation and question ownership
apps/server/src/orchestration-v2/RestartContinuation.ts,apps/server/src/orchestration-v2/DelegatedTaskQuestionReactor.tsRestart continuations and delegated-task questions use the ownership mapping for node-forked child threads. Finalize delegated tasks and recover results
apps/server/src/orchestration-v2/Orchestrator.ts,apps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.tsFollow-up creation, task finalization, and pending-result checks use task-owned runs and delegated-task progress. Tests cover wakes, user turns, and nested delegated work. Report task status, approvals, and results
apps/server/src/mcp/OrchestratorMcpService.ts,apps/server/src/mcp/OrchestratorMcpService.test.tsMCP task views use resolved ownership for task status, approvals, child-task discovery, and result transfers. Tests cover wake results and pending approvals. Estimated code review effort: 4 (Complex) | ~45 minutes
Change: Bug fix · Severity of issue fixed: Medium
Sequence Diagram(s)
mermaid1 sequenceDiagram 2 participant Orchestrator 3 participant delegatedRunOwners 4 participant delegatedTaskRuns 5 participant delegatedTaskProgress 6 participant ParentTask 7 Orchestrator->>delegatedRunOwners: map child runs to task owners 8 Orchestrator->>delegatedTaskRuns: select runs owned by task 9 Orchestrator->>delegatedTaskProgress: calculate task progress 10 delegatedTaskProgress-->>Orchestrator: return progress and result run 11 Orchestrator->>ParentTask: finalize task from task progress Possibly related issues
pingdotgg/t3code#28734— The ownership mapping now assigns restart continuations to the task that owns the source run.pingdotgg/t3code#16603— Task finalization now selects runs by delegated ownership and progress.pingdotgg/t3code#21837— Follow-up finalization and completion handling now account for nested delegated work.pingdotgg/t3code#28448— Provider-wake runs are included in task ownership and result selection.pingdotgg/t3code#26294— Approval reporting now associates nonterminal runs with their delegated task.pingdotgg/t3code#16739— Ownership-based finalization uses task progress when selecting results after cancelled or stopped work.
Suggested labels:
bugfix,size:LSuggested reviewers:
t3dotgg,maria-rcks
Merge Risk: External image Minimal · up to 49fe1
The change keeps a parent in Working while a resumed child waits on its own subagent. No actionable merge-blocking risk was found. Runtime ordering across providers was not executed in this review, which is normal validation uncertainty rather than a concrete defect.
Pre-merge checks: Passed 4
Check name Status Explanation Title check Passed The title names the core fix: a parent stays Working while a resumed child waits on its own subagent. The changeset holds follow-up tasks open until their owned runs reach result_available, using the … Description check Passed The description follows the repository template closely. It has a Problem section with reproduction details (Codex parent, child, grandchild, main commit aee76a8b47) and a Change section explaining th… Linked Issues check Passed Issue #30395requires the parent to remain Working while an existing child follow-up waits on delegated work.delegatedRunOwnersanddelegatedTaskRunsassign child runs to the correct task. `final…Out of Scope Changes check Passed The production changes remain within issue #30395. They centralize run ownership and apply it to finalization and related delivery paths that must identify the task responsible for a wake or continuat…Full details: Title check
Explanation
The title names the core fix: a parent stays Working while a resumed child waits on its own subagent. The changeset holds follow-up tasks open until their owned runs reach result_available, using the new delegatedRunOwners ownership helper, which addresses the reported symptom. The title follows conventional commit style and is specific enough for a teammate scanning history.
Full details: Description check
Explanation
The description follows the repository template closely. It has a Problem section with reproduction details (Codex parent, child, grandchild, main commit aee76a8b47) and a Change section explaining the ownership model and where it is used. The Scope and approval section links issue
#30395and states it was triaged via the automated issue flow. The Verification section lists specific focused tests with before/after failures, the check:changed run, and a real-app Codex reproduction with transcripts and recordings, and it states what was not checked live (mobile, remote delegation, failure/cancel/interrupt variants). It also names the agent and harness used, as the template requests. The Scope section relies on an automated issue triage rather than explicit maintainer approval, which is a possible gap against the template's requirement for a triaged issue or maintainer-approved discussion. Overall the description is complete enough to pass.
Full details: Linked Issues check
Explanation
Issue
#30395requires the parent to remain Working while an existing child follow-up waits on delegated work.delegatedRunOwnersanddelegatedTaskRunsassign child runs to the correct task.finalizeAppOwnedSubagentTasknow uses task-specificdelegatedTaskProgressbefore finalization. Follow-up joining, result transfer, approvals, questions, thread-read acknowledgement, and restart continuation use the same ownership model. NewDelegatedCompletionDelivery.test.tscases cover the grandchild wait, queued and completed later follow-ups, and provider or user wakes. The reported runtime result reaches the parent asCHILD_DONE.
Full details: Out of Scope Changes check
Explanation
The production changes remain within issue
#30395. They centralize run ownership and apply it to finalization and related delivery paths that must identify the task responsible for a wake or continuation. The added tests cover those task-ownership cases and prevent regressions. No unrelated feature or remote-delegation change is shown.
Finishing Touches
Generate docstrings
- Commit to this branch
- Create a new PR
Generate unit tests (beta)
- Commit to this branch
- Create a new PR
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
External image Recent review info
-
External image Run configuration
- Source mode: Auto
- Repository: pingdotgg/t3code
- Branch: fix/issue-30395
- File: .coderabbit.config.ts
- Commit: 49fe1ce
- Layers: Repository TS config
- Review profile: CHILL
- Plan: Team
- Run ID:
e641d37a-ef34-437b-9bb8-e87701e925c2
External image Commits
Reviewing files that changed from the base of the PR and between 8bc344bd9c311de4b8cab9e0e5d9db8f2d963502 and 49fe1cef3ed45b8c533ddeda84a1dd4506a89725.
External image Files selected for processing: 8
apps/server/src/mcp/OrchestratorMcpService.test.tsapps/server/src/mcp/OrchestratorMcpService.tsapps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.tsapps/server/src/orchestration-v2/DelegatedTaskQuestionReactor.tsapps/server/src/orchestration-v2/Orchestrator.tsapps/server/src/orchestration-v2/RestartContinuation.tsapps/server/src/orchestration-v2/SubagentProjection.test.tspackages/provider-core/src/server/subagentProjection.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.
External image Recent review info
-
External image Run configuration
- Source mode: Auto
- Repository: pingdotgg/t3code
- Branch: fix/issue-30395
- File: .coderabbit.config.ts
- Commit: 49fe1ce
- Layers: Repository TS config
- Review profile: CHILL
- Plan: Team
- Run ID:
e641d37a-ef34-437b-9bb8-e87701e925c2
External image Commits
Reviewing files that changed from the base of the PR and between 8bc344bd9c311de4b8cab9e0e5d9db8f2d963502 and 49fe1cef3ed45b8c533ddeda84a1dd4506a89725.
External image Files selected for processing: 8
apps/server/src/mcp/OrchestratorMcpService.test.tsapps/server/src/mcp/OrchestratorMcpService.tsapps/server/src/orchestration-v2/DelegatedCompletionDelivery.test.tsapps/server/src/orchestration-v2/DelegatedTaskQuestionReactor.tsapps/server/src/orchestration-v2/Orchestrator.tsapps/server/src/orchestration-v2/RestartContinuation.tsapps/server/src/orchestration-v2/SubagentProjection.test.tspackages/provider-core/src/server/subagentProjection.ts
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 7 remain after this review.
Thanks, @juliusmarminge, for the earlier work and thorough reproduction. Closing as a duplicate of your newer #33539: both fix the same premature follow-up completion, but this older branch conflicts with current main while the newer branch merges cleanly.