Repository navigation
Delegated task reports finished while its child thread still has running work #16603
Description
Activity
Note
Grok responding on behalf of Julius.
Confirmed on current
main: an app-owned delegated task can finalize asresult_available/completedwhile the child still has live backgroundcommand_executionwork.Main bug
delegatedTaskProgressdecidesworking/waiting_for_children/result_availablefrom:- non-terminal work runs
- active child subagents / pending completion delivery
- provider-thread
pendingBackgroundTasks
It does not look at active turn items.
finalizeAppOwnedSubagentloads the child withoutturnItems, calls that helper, and finalizes as soon asprogress.state === "result_available".So a Codex child that starts a long-lived shell (
countsForRun: false/ turn ends without waiting) can look “done” to the parent while the process is still alive — matching the state-DB evidence in the report.The shared
pendingBackgroundTurnItemshelper already exists and is used elsewhere in the orchestrator (e.g. interrupt cleanup). It is the natural check to fold intodelegatedTaskProgress(with callers loadingturnItems).Secondary path (distinct)
t3_thread_sendinto an already-finalized child can start new runs without reopening parent task tracking / delivering the later result. That overlaps open #13490 and open PR #15004 (follow-up result delivery). Those do not fix the premature-finalize case above.Loosely related: #13625 (completion sound while background work runs), #15993 (stale background banner).
Fix direction: include
pendingBackgroundTurnItems({ turnItems, runs })indelegatedTaskProgress(and load turn items in both finalize / status callers); keep finalization deferred until those items end. Separately, for send-into-finalized-child, either reject or reopen tracking (coordinate with #15004).Labeling
bug+via-triage.Additional user-observed scenario with nested subagents:
Root thread: completed `-- Subagent A: completed `-- Subagent B: still runningFrom the original root thread, the remaining descendant activity is not visible, so the delegated workflow appears finished while B continues working.
This is an observation, not an independently reproduced case. It is unclear whether it has the same underlying cause as the
command_executiongap described above.Consolidating the related report from #16902 here to avoid parallel tracking.
Area: apps/server
Steps to reproduce
delegate_taskto a Codex child that starts a long-running shell command (a bot, a test watcher) and ends its turn without waiting for it.task_status, or look at the parent once it settles.Expected: The task stays in progress (or reports
waiting_for_children) while the child's command is still running, and the parent stays Waiting.Actual: The task finalizes as
completed/result_availableand the parent can settle to Done, while the child thread still has a runningcommand_executionitem and the process is alive.delegatedTaskProgress(SubagentProjection.ts:207-259) checks runs, subagent entities and the provider roster, but not active turn items, andfinalizeAppOwnedSubagent(Orchestrator.ts:8472-8488) finalizes on that result.A related path:
t3_thread_sendinto an already-finalized child (ThreadManagementService.sendToThread) starts new runs there, but the parent task stayscompletedand its later result is never delivered (OrchestratorMcpService.ts:1058-1077,Orchestrator.ts:8537-8546).Evidence (0.0.46-nightly.20261004 state DB): 3 of 145 completed delegated tasks since Oct 1 finalized while their child had live command items (2 still running now, one confirmed alive with
pgrep). 5 later runs across 3 finalized children.Possible fix: include
pendingBackgroundTurnItems({ turnItems, runs })indelegatedTaskProgress(and load turn items in both callers), retrying finalization when those items end. For the send path, reject sends into finalized app-owned children or reopen task tracking.Impact: Minor bug or occasional failure.