Repository navigation
[Bug]: task_status reports workState=working for a delegated task whose run never started (no turn items, provider thread not_loaded) #24324
Description
What happens
task_status for a delegated task reports workState: working while the child's run never started: the child thread exists, its run is starting, the provider thread is not_loaded, and there is no turn item at all. A parent that watches budgets through task_status therefore sees an active task and waits the full budget.
Evidence
- Dispatcher friction 2026-10-23T00:02Z: "task_status says workState=working for runs that never started, so wedge detection by budget missed lead-23832-r1 for 3h".
- On 2026-10-24 a sweep of 94 delegated issue leads on the VMs found 16 whose run had been
startingfor 9 to 92 minutes with zero turn items (cause: https://git.cafe/pingdotgg/t3code/issues/24300, the shared Codex app-server not answeringthread/start). Every one of them wasworkingaccording totask_status. Readingorchestration_v2_projection_runs.statusandorchestration_v2_projection_turn_itemsinstatev2.sqliteon the VM was the only way to tell.
Expected
task_status should distinguish "run requested, provider has not started it" from "working": expose the run status (starting vs running), the provider thread status, and the time of the first turn item (or null). A parent can then treat "no turn item N minutes after launch" as not started and re-dispatch instead of waiting for a budget that never begins.
Where
T3 Code MCP task_status, delegated tasks to a linked environment (Freestyle VMs), Codex provider, T3 server from the 2026-10-22 preview rollout.
Activity
ReneFr81 commentedon Oct 29, 2026
On main at
dd148481531a0a090780a2ade20588566db099a2, remote child identity is persisted in the parent's task payload.In a two-day sample of one multi-machine setup, all 233 remote task records had persisted
remoteChild.environmentId,remoteChild.threadIdandremoteChild.runId. All 230 terminal records hadcompleted_at. The localchild_thread_idandprovider_thread_idcolumns were null for every remote task, which matches the implementation: the launch recordsremoteChild, and the projection stores the full subagent payload. Looking only at the indexed columns would miss the remote identity.The timing gap remains in
readRemoteTask: until a result arrives, it returnsstatus: "running",workState: "working"andchildRunId: null. It exposes no remote run status or provider-turn start/end timestamps. The parent's task timestamps also measure different events:startedAtis set when the accepted launch is recorded, andcompletedAtwhen the parent handles the completion report.For an orchestrator, that leaves two practical problems: its task status cannot distinguish an accepted task whose provider has not started from one executing, and its saved task duration cannot separate startup/queue delay from provider execution and completion delivery. This inspection confirms the metadata and code paths; it is not a fresh live reproduction of a never-started run.
Could this issue's fix include a persisted remote lifecycle summary, keyed to the existing
remoteChild.runId, with remote run status/request time and nullable provider-turn start/end times, exposed throughtask_status? The existing remote follow responses could carry that summary. A run that never starts would retain null provider timestamps; a completed run would retain its remote timestamps even if the parent receives the result later.For now, a separate remote
t3_thread_readalready exposes run-levelrequestedAt,startedAtandcompletedAtinrecentRuns. Those are useful for investigation, but they are not a provider-timing record on the parent's task.