Follow-up turns sent to completed delegated child threads stay queued forever after a T3 restart #42

Observed (2026-10-14/15, ePC-SAFT repository-managed project, root thread 9354899b)

T3 restarted at about 23:22 UTC on 2026-10-14; it cancelled two running delegated review tasks. Right after it came back I continued two completed delegated child threads with t3_thread_send (mode auto), the documented way to give a finished child a follow-up turn:

• Both threads showed status queued, activeRunId: null, pendingRequestCount: 0, for about 2.5 hours.
• Nothing else in the project was running; the repository's 4 worker slots were free. The repository was not paused.
• Cancelling the queued run (t3_queue_cancel) and resending with t3_thread_send mode auto returned delivery: "started", but the new run (ordinal 3) also stayed queued with startedAt: null.
• A fresh delegate_task (with issue) started a new child immediately (status: running).

get_repository_orchestration also reported milestones 6 and 22 as awaiting_approval throughout, with no pending request visible to the orchestrator. Milestone 22 has an eligible unclaimed issue (pingdotgg#494) that never auto-started. This may be the same stuck dispatcher.

Expected

A follow-up turn on a completed child thread starts when capacity is free, as it did before the restart (the same pattern worked repeatedly earlier on 2026-10-14).

Workaround

Cancel the queued run and start a fresh delegate_task whose prompt carries the needed context. This loses the child's conversation context and, for managed issue workers, means a new worktree, so the worker has to cherry-pick the old branch's commit.