Feature: Parent is never notified when a delegated child finishes a follow-up turn (V2)

[AmishHillBilly]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Parent calls delegate_task (async). The child finishes and the parent is woken as expected.
2. Parent sends the same child more work with t3_thread_send.
3. The child finishes that follow-up turn.

Expected behavior

The parent is woken for the follow-up result, the same as for the first one.

Actual behavior

The parent is never woken. The result only shows up if the parent polls task_status (latestTerminal*).

It looks like finalizeAppOwnedSubagent returns early once the child has already delivered one result, so every later turn is skipped:

t3code/apps/server/src/orchestration-v2/Orchestrator.ts

Lines 8168 to 8175 in 5239fe0

	const existingResultTransfer = parentProjection.contextTransfers.find(
	(transfer) =>
	transfer.type === "subagent_result" &&
	transfer.sourceThreadId === childThreadId &&
	transfer.targetThreadId === parentThreadId,
	);
	if (existingResultTransfer !== undefined) {
	return;

This is on the V2 branch (#2829), not main. It's different from #12285 / #13338: it happens with just one child, and #13338 doesn't change this check.

Impact

Major degradation or frequent failure

Version or commit

0.0.43-preview.20260923.2138 (Linux). Mac:

Environment

Linux (self-hosted server) and macOS. Claude and Codex providers.

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Start a new delegate_task for each follow-up instead of using t3_thread_send, or have the parent poll task_status.

[juliusmarminge]

Triage

Verdict: Not a bug. On t3code/codex-turn-mapping (PR #2829, HEAD f6da5af0f0) an async child wakes its parent once, when the delegated task’s result is first published. A later t3_thread_send turn is recorded on task_status.latestTerminal* and does not wake the parent. This code is not on main.

The report’s mechanism is right, and it is still the behavior at this HEAD. It is a separate issue from #12285 / #13338.

What the report gets right

handleTerminalRun does call finalizeAppOwnedSubagent for every terminal child run, including a follow-up (Orchestrator.ts around 9035–9038). That function returns immediately when the parent already has a subagent_result transfer for that child thread:

      const existingResultTransfer = parentProjection.contextTransfers.find(
        (transfer) =>
          transfer.type === "subagent_result" &&
          transfer.sourceThreadId === childThreadId &&
          transfer.targetThreadId === parentThreadId,
      );
      if (existingResultTransfer !== undefined) {
        return;
      }

Those lines are unchanged since 6952f57c88c. The check is on the thread pair, not the child run, so the second terminal turn never creates another transfer and never offers another wake. task_status still exposes that turn: summary stays the original published result, and latestTerminalRunId / latestTerminalStatus / latestTerminalSummary move to the follow-up. That matches the reported symptom on 0.0.43-preview.20260923.2138 and on this newer HEAD.

Why that is the contract

completionWake: "always" (OrchestratorMcpService.ts around 1402) is the wake for the delegated task’s published completion. The async delegate_task text tells the parent to end the turn instead of polling for that completion. It does not promise a wake for later sends.

task_status and the V2 MCP doc say the published summary and result transfer stay stable after publication, and that later non-monitor turns are latestTerminal* only:

• apps/server/src/mcp/toolkits/orchestrator/tools.ts (task_status description)
• docs/orchestration-v2/orchestrator-mcp-server.md lines 267–270 (03ad271bad, “distinguish delegated task results from completed turns”)

The integration test encodes the same outcome. After a queued follow-up completes, summary and resultContextTransferId are still the original delegation, and latestTerminalResultContextTransferId is null (OrchestratorMcpToolkit.integration.test.ts around 3344–3354, from 92006e779c).

Startup recovery uses the same latch. getRecoveryThreadIds("subagent-results") only revisits a child that is terminal and has no subagent_result transfer at all (ProjectionStore.ts around 484–489 and the SQL around 3318–3323). A follow-up after the first transfer is not recovered into a wake either.

Deleting only the early return would still not wake the parent after the first delivery settles. planDelegatedCompletionDelivery refuses to claim or offer again once completionDelivery is acknowledged, delivered, or disposed (Orchestrator.ts 7897–7911). The early return runs before that planner, so it is the gate that actually fires. It also keeps the published summary from being overwritten by the follow-up text.

Relation to #12285 and #13338

#12285 is the per-cohort lifetime cap: settledDeliveryCount >= 2 stops wakes for other children delegated in the same parent run. #13338 (open) removes that cap in planDelegatedCompletionDelivery, finalizeDelegatedCompletionDelivery, and dispatchNotificationAccepted. Its diff does not change the existingResultTransfer return, the one-result recovery query, or the “published summary stays stable” test. One child plus a follow-up send still would not wake the parent with that PR applied.

If a follow-up wake is wanted

That is a feature change to the published-result contract, not a fix for a skipped first wake. It would need a per-run result transfer, a new completion delivery after the previous one has settled, a recovery predicate that notices a newer terminal run, and updates to the doc and the integration test that currently require latestTerminalResultContextTransferId: null. summary could stay stable while the wake carried latestTerminal*.

Workarounds

These already match the implementation:

• t3_thread_wait on the runId returned by t3_thread_send blocks the current parent turn until that follow-up finishes. Waiting does not acknowledge a delegated result.
• Poll task_status and read latestTerminal*. hasPendingChildRuns covers a follow-up that is still queued or running.
• delegate_task again if a new wake is required. That starts a new child and does not continue the previous child’s conversation.

Disposition

Take off needs-triage. Drop bug unless this is retitled as a feature request for a wake on each later child turn. Do not close it as a duplicate of #12285 or #13338.