Failed turns discard partial output and surface opaque "run failed" errors (retry policy itself works)

[gg1356088]

Summary

Two UX problems around failed turns, plus four smaller requests. For the record: the
retryPolicy mechanism itself works correctly — this is not a "missing retry" report.

Environment

• DSH desktop build, app.asar built 2026-09-29, profile desktop
• @deepseek-ai/dsh-llm-pi-ai v0.2.0-rc.2, route ark, api: anthropic-messages
• @deepseek-ai/dsh-llm-retry present

Verified: retry works

• Default retryPolicy = normal, 5 attempts, eligible codes
  EMPTY_RESPONSE / RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT, backoff 500 ms → 10 s with jitter.
• Observed 218 llm/retry / llm/retry-started events across 9 local sessions.
• After explicitly setting retryPolicy: {mode: normal, maxRetries: 10} on the route, a later
  session's llm/retry event carried
  policyKey: ["normal",10,["EMPTY_RESPONSE","RATE_LIMIT","SERVER",...]] — confirming the
  configured policy is loaded and applied.

Failure taxonomy (9 sessions / 179 turns)

Outcome	Count
completed	147
provider content moderation rejection (SensitiveContentDetected)	14
quota window (403 ... 5-hour usage limit)	7
rate limit (429 AccountRateLimitExceeded)	6
MISSING_CREDENTIAL (no credential for provider route "ark")	6
401 authentication_error	1

Note: 22 of the 28 failures are classes that are non-retryable by nature (moderation, quota,
credential, auth). The 6 rate-limit failures surfaced after the 5 attempts were exhausted.

Requests

1. Preserve partial assistant output when a turn fails on a provider error.
   Today the whole turn's generated text is discarded and the UI shows only a generic
   "run failed". From the user's side this reads as a silent disconnect with no output at all.

2. Surface a classified, human-readable failure reason instead of a generic "run failed" —
   distinguish content-moderation rejection, quota exhausted, credential missing,
   authentication failure, and sustained rate limiting.

3. For quota-class errors, include the window reset time (or remaining quota) when the
   provider exposes it. Currently the user can only guess and retry blindly.

4. Validate credential references at startup and warn, instead of failing at request time
   with MISSING_CREDENTIAL — which looks like a random mid-session breakage.

5. For content-moderation rejections, say that retrying will not help. Those codes are
   (correctly) outside the retryable set, but nothing in the UI tells the user that, so the
   natural reaction is to retry a request that can never succeed.

Note

No secrets, tokens, hostnames, or user content are included above; failure counts and plugin
identifiers only. Happy to provide additional detail (event shapes, timings) if useful.

[PerryLink]

你要的那个能力代码里已经有了——只是没用在"失败"这条路径上

1. 既有机制（HEAD = dsh-v0.2.1-alpha.1）

packages/core/agent-loop/src/agent.ts：

const content = live.interruptedBlocks()      // :449
…
interrupted: true,                            // :462

packages/core/agent-loop/README.md:118 也把这个意图写明了：

a cancelled stream appends an interrupted: true anchor with the delivered prefix so the next request contains what the user saw

⇒ "保留已交付的部分输出"这套机制已经存在，而且是刻意设计的——用在被取消的流上。

2. ⇒ 所以你这条的诉求可以写得很精确

不是"请新增保留部分输出的能力"，而是"把已有的这套待遇从『取消』扩展到『失败』"：

因错误而结束的轮次应当像被取消的轮次一样，保留已交付的前缀（并在 UI 上明确标出"本轮中断，以下是已收到的部分"）；此外错误信息应带上底层原因，而不是只显示 run failed。

这个写法比"请别丢结果"强得多：它指出机制已存在、只差一处适用，维护者不必先评估要不要做这个功能。

3. 关于 run failed 为什么"不透明"

同一套 pi-ai 适配器里，错误分类是基于文本的（classifyPiAiError(message: string) 只接收一个字符串）。⇒ 于是任何没被文本匹配命中的原因，最终都会退化成一个通用文案。建议你在报告里把这句因果写出来（"不透明"不是文案没写，而是结构化信息在分类那一步就丢了），并顺带引用本周同因的两条：#8844（稳定错误码被丢弃）、#8722（措辞不符导致不重试）。三条合起来足以支撑一次接口级修改。

4. 你声明的边界我认同，建议保留

你写"For the record: the retryPolicy mechanism itself works correctly — this is not a 'missing retry' report"。⇒ 这句话很有用：它防止维护者把这条误读成重试缺陷。建议把它放在摘要第一句，而不是放在正文里。

5. 请补两样

1. 那次失败的实际错误原文（含 cause，若日志里有）——它是"不透明"这一半的证据；
2. 版本：你写 0.2.0-rc.2；⚠️ 当前最新是 0.2.1-alpha.1，请确认 agent.ts 的 interrupted 分支在新版是否仍只覆盖取消路径（我核到的是是）。

一条边界

我确认的是**interrupted: true 锚点与"保留已交付前缀"这一机制存在**（agent.ts:449/462 + README 的表述）。该机制在失败路径上是否已被复用以你的现场为准——我核到的是取消路径在用。

[gg1356088]

Follow-up: requested evidence + version confirmation

Thanks @PerryLink — the pointer to interruptedBlocks() / interrupted: true is exactly what we needed. Both follow-ups below.

1. Version confirmation (0.2.1-alpha.1)

Confirmed your reading: in 0.2.1-alpha.1, the interrupted: true anchor is still only wired into the cancelled path (agent.ts interrupt handling); the failure path (turn/end.reason.kind === "error") discards live.interruptedBlocks(). So the gap stands on the current line.

2. Raw error evidence (request #1–2 of the original post)

Captured from local session.v4.jsonl.zstd (assistant/attempt → stream[].chunk.finish.reason, DSH 0.2.0-rc.2, route ark / anthropic-messages):

Content-moderation rejection — surfaces as PI_AI_ERROR, no hint that retrying is pointless:

{
  "kind": "error",
  "failure": {
    "message": "{\"error\":{\"code\":\"SensitiveContentDetected\",\"message\":\"The request failed because the input may contain sensitive information. Request id: 02179110…d4\",\"param\":\"\",\"type\":\"BadRequest\"},\"type\":\"error\"}",
    "code": "PI_AI_ERROR"
  }
}

Note the double defect: the provider's structured code (SensitiveContentDetected) is buried inside a stringified JSON message, and the wrapper code degrades to the generic PI_AI_ERROR — so the UI can neither classify it nor tell the user "retrying will not help" (original request #5). Same shape for quota errors (403 … 5-hour usage limit, surfaces as AUTH).

Sustained rate-limit after retries exhausted (429, 36 occurrences in one session):

{
  "chunk": {
    "type": "finish",
    "reason": {
      "kind": "error",
      "failure": {
        "message": "429 {\"error\":{\"code\":\"AccountRateLimitExceeded\",\"message\":\"Requests are too frequent. Please reduce your request frequency, wait a short moment, and retry your request. Request id: 02179095…1d9\",\"param\":\"\",\"type\":\"TooManyRequests\"}}",
        "code": "RATE_LIMIT"
      }
    }
  }
}

The provider does return AccountRateLimitExceeded + TooManyRequests + request id, but again only inside the stringified message.

3. Failure census across 9 local sessions (the numbers behind the original table)

wrapper code	count	underlying provider error
PI_AI_ERROR	24	SensitiveContentDetected (non-retryable, but indistinguishable from transient)
AUTH	14	403 permission_error — 5-hour usage limit (non-retryable within window)
RATE_LIMIT	117	429 AccountRateLimitExceeded (retryable, retries eventually exhausted)
CONTEXT_WINDOW_EXCEEDED	5	pi-ai context overflow
MISSING_CREDENTIAL	6	credential service lookup failure
TRANSPORT	1	stream ended without stop reason

4. Agreement on the fix shape

Given classifyPiAiError(message: string) is the choke point, we support the interface-level change: pass the parsed provider error object (or at least code + request id) through to the failure reason, and map the already-known non-retryable classes to explicit user-facing states. Happy to test a preview build against the ark route.

[PerryLink]

你补的两条我都收下——而第二条是一条独立且重要的新事实

1. 版本确认（你做的正是我请的那一步）

你在 0.2.1-alpha.1 上确认：interrupted: true 锚点仍然只接在"取消"路径上，而 failure 路径（turn/end.reason.kind === "error"）丢弃 live.interruptedBlocks()。⇒ 我此前核到的"机制存在、但只用于取消"在最新线依然成立，谢谢复核——这让诉求可以按当前版本写。

2. ⭐ 新事实：内容审核拒绝被归类成 PI_AI_ERROR

你从 session.v4.jsonl.zstd（assistant/attempt → stream[].chunk.finish.reason，0.2.0-rc.2 / 路由 ark / anthropic-messages）抓到：内容审核拒绝以 PI_AI_ERROR 出现，且没有任何"重试无用"的提示。

⇒ 这条把三条独立报告串成一条链（建议你在报告里就按这三句写）：

1. 审核是服务端行为（跨客户端、跨模型一致 ⇒ 已由 #8164 证明）⇒ 客户端改不了规则；
2. 但它被归类成 PI_AI_ERROR ⇒ 看起来像可重试的失败（而重试必然再次被拒）⇒ 这是客户端该修的；
3. 且一次命中之后该会话此后每轮都失败（#7879、#8830 实测）⇒ "不可恢复"也是客户端该修的。

3. 为什么第 2 点值得单独成条

我此前核到：错误分类是基于文本的（classifyPiAiError(message: string) 只接收一个字符串）。⇒ 于是"审核拒绝"这种语义明确、且重试无意义的错误，只要文案没被匹配到，就会落到兜底码，而兜底码的语义是"未知" ⇒ 调用方与用户都无法判断该不该重试。

建议诉求写成：

内容审核拒绝应当被单独归类（或至少带上"不可重试"的标记），并在 UI 上说明"该内容被服务端拒绝，改写后重试"——而不是呈现为一个通用失败码。

4. 请补一样

那段 finish.reason 的原文（你说抓到了，把 JSON 贴全）⇒ 有了它，"审核拒绝确实以该码出现"就从描述变成可比对的事实；同时建议附上同一会话在改写内容后成功的记录（这能证明"改写可绕过"，正是第 3 节诉求的依据）。

5. 一条边界

我确认的是分类器只收字符串、因此语义明确的错误会落到兜底码这一机制。**"审核拒绝以 PI_AI_ERROR 出现"**以你抓到的原文为准——我没有该现场。