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

Ouverte
  • Quelque chose ne va pas ?
#36,147 3 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
45/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
backend-api-design

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
TypeScript
Étoiles
24.8k
Forks
6.4k
Merge moyen
59 min
PR mergées (30 j)
418

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de pingdotgg/t3code

Toutes les issues de pingdotgg/t3code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.