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

Offen
  • Stimmt etwas nicht?
#36,147 3 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
45/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
typescript
Bereich
backend-api-design

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
TypeScript
Sterne
24.8k
Forks
6.4k
Ø Merge
59 Min.
Gemergte PRs (30 T.)
418

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus pingdotgg/t3code

Alle Issues in pingdotgg/t3code

Ähnliche Issues

Weitere Issues zu TypeScript

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.