[Bug] subagent outcome drops turn-end error detail, so 429/quota failures arrive opaque

[ujji-k06]

[Bug] subagent outcome drops turn-end error detail, so 429/quota failures arrive opaque

Component: @deepseek-ai/dsh-subagent-in-process-driver
Status: present in published dsh-subagent-in-process-driver@0.2.0-rc.2

What happens

A settled child is returned as { output, stopReason }, where stopReason is produced by flattening the turn-end reason to a bare kind:

const recorded = toStopReason(lastEnd?.data.reason);
...
return { output, stopReason };

The turn-end reason carries the actual failure detail — message, detail, status, statusCode, code — which is where provider 429 / quota-exhaustion surfaces. All of it is discarded, so the parent agent cannot distinguish rate limiting from a crash or a normal error, and cannot decide whether to retry, switch models, or give up.

Expected

The settled outcome should retain enough detail to diagnose the failure, or at minimum expose a bounded diagnostic string.

Suggested change

Build a bounded diagnostic from the reason and attach it to the returned value:

function stopReasonErrorDetail(reason) {
  if (reason?.kind === "completed" || reason == null) return undefined;
  const parts = [String(reason.kind ?? "error")];
  for (const key of ["message", "detail", "status", "statusCode", "code"]) {
    const value = reason[key];
    if (value !== undefined && value !== null && String(value).length > 0) parts.push(key + ": " + String(value).slice(0, 500));
  }
  return parts.join(" | ");
}

We currently carry this as a local patch; it can be dropped once handled upstream.

[PerryLink]

这是错误明细在传递中被丢掉——与本周另外两条同因

1. 你的诉求我这样理解（请确认）

子代理结束时，turn 结束的错误明细没有随结果传出来，于是 429/配额类失败在上层只表现为一个笼统的失败 ⇒ 用户无法区分"限流，等一会儿重试"与"真的坏了"。

建议把诉求写成一句可判定的：

子代理的结果应当携带 turn 结束时的错误原因与状态码（至少 429/配额类要可辨识），使上层能区分"可重试的限流"与"不可重试的失败"。

2. 这已经是本周第三条同因报告（建议互相引用，合成一次接口级修改）

帖	丢失的是什么
#8844	provider 的稳定错误码（classifyPiAiError 只收一个字符串 ⇒ 结构化信息进不来）
#8722	措辞不符 ⇒ 落到兜底 PI_AI_ERROR ⇒ 不重试
你这条	子代理结算时丢掉了 turn-end 的错误明细

⇒ 共同根源：结构化错误信息在某一层被降级成"一个字符串/一个笼统失败"。三条合起来足以支撑一次接口级修改（把 code/cause 一路带上去），比各自修更容易被采纳。

3. 请补三样

1. 上层实际收到的内容（子代理结果里那段错误文本原文）与子代理内部实际发生的错误（含状态码）——两者的落差就是证据；
2. 是否有可复现路径（例如对配额做一次必然 429 的调用）——若能，这条就从"我遇到过一次"变成确定性缺陷；
3. 版本：请写版本（当前最新 0.2.1-alpha.1）。

4. 关于可复现性

429/配额类天然可造（例如把并发打满或用一个受限 key）。⇒ 建议直接给出一次可复现的调用序列——这是这条最能提升说服力的地方。

一条边界

我没有核对子代理结算路径的代码（你给的是行为描述）。上面第 2 节的"同因"判断基于另两条已核实的报告（#8844：分类器只收 message: string；#8722：措辞失配）。你这条的丢失点以第 3 节的两份错误文本对照为准。