delegate_task reports a transient provider error as failed while the child keeps running and later completes

Abierto
  • ¿Algo no está bien?
#36,147 3 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend-api-design

Línea de trabajo

Start in apps/server/src/mcp/OrchestratorMcpService.ts by tracing the wait handling around line 1813 and the heldForRestart / delegatedTaskResultPending logic around line 1540. Compare how transient failures and restart continuations affect task status, child execution, and node IDs. Done means a failed result cannot leave a child running unnoticed, and completion notifications remain traceable to the task returned by delegate_task.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

What happened

A delegate_task call came back as failed right away, so the parent agent retried it. The first child was still running, though. It finished later and reported completed, so both children did the same work at the same time and edited the same files.

Diagnosis
  1. delegate_task (mode: "wait", Claude provider, claude-fable-5-2, effort high) returned immediately with status: "failed", workState: "result_available", latestTerminalStatus: "failed". The summary was a transient upstream error: Failed to authenticate. API Error: 403 Attention Required! | Cloudflare. Native Claude subagents in the same thread hit the same 403 at about the same time, so this was an edge or auth blip, not a bad credential. It lines up with a Claude incident, Elevated errors on claude.ai, Claude Code, and platform.claude.com (opened 09:58 UTC for authentication failures, fix deployed 11:05 UTC). The upstream error is only the trigger. This report is about how T3 handles a provider failure, which any provider outage can cause.
  2. The parent retried with an identical delegate_task. That child completed and said files had been changed under it by "another writer".
  3. Later the parent received a completed notification with the full result of the first task. It arrived under a different node id than the one delegate_task had returned:
    • returned: node:delegated-task:command%3Amcp%3A<uuid>%3Adelegate-task%3A<task-id>
    • notified: node:delegated-task:<other-id>

Likely code path:

  • apps/server/src/mcp/OrchestratorMcpService.ts (around line 1813): wait reports result_available plus the run's terminal status as soon as one child run ends, so a single failed run becomes the task's final result.
  • The same file (around line 1540, heldForRestart / delegatedTaskResultPending) holds the status back only when the child will be continued after a T3 restart. Nothing similar covers a run that fails on a transient provider error and then continues.
  • T3 did not restart during this. The desktop app last installed an update and relaunched at 07:58 UTC, nearly two hours before the failure, and the server process ran without a restart from then on. So restart continuation is not what kept the child going.
  • Because the completion arrived under a different node id, the parent had no way to tie it back to the "failed" task and stop its retry.

This looks related to #29988 (a delegated task fails on a passing provider error, so a retry repeats finished steps). That issue is closed as completed, but no fix is linked to it, and it doesn't cover the "failed" child carrying on and completing on its own.

Steps to reproduce

Observed once, not yet a deterministic repro:

  1. From a Claude thread, call delegate_task with mode: "wait" for a long task on a Claude model.
  2. Have the provider return a transient error (here, a Cloudflare 403) early in the child's run.
  3. delegate_task returns failed. Retry it.
  4. Both children run at the same time, and the first one later notifies completion under a different node id.

Expected: a transient provider failure keeps the task working until the child really stops (as across restarts), or a task reported failed has its child stopped. A delegated task's node id should also stay the same from the delegate_task result through to its completion notification.

Version

0.1.10-nightly.20261113.4616 (desktop app, local server)., running since 07:58 UTC with no restart during the incident

Environment

macOS 26.7.1 arm64, Node v26.13.0, Claude Code 2.1.311

Evidence

Timeline (UTC, 2026-11-13), from the parent thread's activity:

Time Event
07:58 Desktop update to 0.1.10-nightly.20261113.4616 installed and the app relaunched; no restart after this
~09:43 delegate_task called
09:47:17 It returns failed with the 403
09:53 Parent retries with a second delegate_task
09:58 Claude incident opened
10:00:43 The first task finishes as completed under node:delegated-task:<other-id>
10:07:45 The retry completes and reports "another writer" rewrote the files at 10:00
10:51:08 The parent receives the late "Delegated task … finished" notification for the first task. It was queued at 10:00:43 but only delivered when the parent's current turn ended 
delegate_task -> status: failed, workState: result_available, latestTerminalStatus: failed
  summary: "Failed to authenticate. API Error: 403 Attention Required! | Cloudflare"
retry delegate_task -> completed ("another writer finished it while I was reading")
later notification: node:delegated-task:<other-id> "…" status: completed (full result of the first task)
Related issues
  • #29988, the same retry-duplicates-work problem; closed with no linked fix
  • #36149, how these provider errors are displayed

🤖 Claude Opus 5.5

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
59 min
PR fusionados (30 d)
418

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.