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

オープン
  • 何か問題がありますか？
#36,147 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
45/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
backend-api-design

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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

主要言語
TypeScript
スター
24.8k
フォーク
6.4k
平均マージ
59分
マージ済み PR（30日）
418

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

pingdotgg/t3code のほかの issue

pingdotgg/t3code の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。