[Bug] pi-ai adapter discards the provider's stable error code, so upstream stream interruptions become non-retryable PI_AI_ERROR

[Matthew-Laplace]

DSH Desktop 0.2.0-rc.2 (nightly) / macOS 26.6.2 (25G83) / arm64 / Bundle ID com.deepseek.dsh
Agent preset cordis; route: @deepseek-ai/dsh-llm-pi-ai, api: openai-responses, no retryPolicy configured (adapter default)

---

Summary

A provider SSE stream returned an error frame carrying a stable provider code:

Error Code upstream_stream_read_error: Upstream response stream was interrupted

upstream_stream_read_error / upstream_http2_stream_error are transport-level stream interruptions
(the relay's own read of its upstream SSE body failed). But the pi-ai adapter throws away event.code
and keeps only the text:

else if (event.type === "error") {
    throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");
}

classifyPiAiError(message) then re-derives a DSH code by regex over that text. The regexes do not cover
the … stream was interrupted wording, so it falls through to the catch-all PI_AI_ERROR. Since the
default normal-mode retry policy only retries
EMPTY_RESPONSE / RATE_LIMIT / SERVER / TIMEOUT / TRANSPORT, the failure is not retried, and the
≈140 KB of tool-call arguments already streamed in that step are silently discarded — the user only
sees one error line.

The core issue: DSH's own documented rule is "consumers route on the code, never on message text",
yet here a stable provider code is downgraded to text and then re-classified by regex.

---

Symptom (observable criteria)

All four hold for a failing turn:

1. turn/end carries the catch-all code:
   {"kind":"error","error":{"code":"PI_AI_ERROR","message":"Error Code <provider_code>: <provider message>"}}
2. The step has no assistant/message — only assistant/attempt (holding the partial stream). The whole step is voided.
3. The turn has no llm/retry / llm/retry-started events at all (outside the eligible set → delegates).
   Measured in one session: retry events per turn = {turn 3: 10}, turn 7: 0.
4. The immediately following turn completes normally on the same provider/model → transient, not misconfiguration.

Control: in the same session, an earlier TRANSPORT failure retried 5 times (llm/retry + llm/retry-started
× 5, budget exhausted). The retry executor works; only the classification is wrong.

---

Deterministic reproduction (no relay or network needed)

1. Fake provider

// fake-responses.js  →  node fake-responses.js
const http = require('http');
const frames = [
  { type: 'response.created', response: { id: 'resp_1', status: 'in_progress' } },
  { type: 'response.output_item.added', output_index: 0,
    item: { type: 'function_call', id: 'fc_1', call_id: 'call_1', name: 'bash', arguments: '' } },
  { type: 'response.function_call_arguments.delta', output_index: 0,
    delta: '{"command":"echo hi"}' },
  // ↓ the frame under test; DSH expects a terminal response.completed here
  { type: 'error', code: 'upstream_stream_read_error',
    message: 'Upstream response stream was interrupted' },
];
http.createServer((req, res) => {
  if (!req.url.endsWith('/responses')) { res.writeHead(404).end(); return; }
  res.writeHead(200, { 'content-type': 'text/event-stream', 'cache-control': 'no-cache' });
  let i = 0;
  const t = setInterval(() => {
    if (i >= frames.length) { clearInterval(t); res.end(); return; }
    res.write(`data: ${JSON.stringify(frames[i++])}\n\n`);
  }, 60);
}).listen(8799, '127.0.0.1');

2. Point a pi-ai route at it

- id: llm-pi-ai
  name: "@deepseek-ai/dsh-llm-pi-ai"
  config:
    providers:
      repro:
        displayName: Repro
        apiKeyEnv: REPRO_API_KEY      # a credential reference name, needs an entry under refs:
        api: openai-responses
        baseURL: http://127.0.0.1:8799
        defaultContextWindow: 272000
        models:
          - id: repro-model
            name: Repro
            input: [ text ]

(An unresolvable apiKeyEnv fails with MISSING_CREDENTIAL, not this bug — add the ref first.)

3. Send one prompt

	Expected	Actual
events	llm/retry + llm/retry-started (transport class → should retry)	no retry events
turn/end	error.code = TRANSPORT (or at least expose the provider code)	error.code = PI_AI_ERROR
message	provider's stable code preserved	Error Code upstream_stream_read_error: Upstream response stream was interrupted (code only inside the text)
partial output	visible notice that it was abandoned	silently discarded, no assistant/message for the step

4. Control

Replace the error frame with a valid {"type":"response.completed", …} → the turn completes normally.

---

Root cause

All snippets below are from app.asar (the @deepseek-ai/dsh-llm-pi-ai stream module; its header comment is
@module dsh-llm-pi-ai/stream). Verifiable with:

cd "/Applications/DeepSeek Harness.app/Contents/Resources"   # app.asar is an uncompressed archive
grep -ac 'Error Code \${event.code}'  app.asar   # 1  → throw site (text only)
grep -ac 'classifyPiAiError'          app.asar   # 2  → classifier (definition + call)
grep -ac 'PI_AI_ERROR'                app.asar   # 4  → catch-all code
grep -ac 'upstream_stream_read_error' app.asar   # 0  → the code is not DSH's
grep -ao 'throw new Error(`Error Code [^`]*`' app.asar
# → throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");

① Throw site: stable code downgraded to text

else if (event.type === "error") {
    throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");
}

event.code only ever becomes part of a string; nothing structured carries it.

② Classifier: regex does not cover the "interrupted" wording

function classifyPiAiError(message) {
    if (/\b(?:401|403)\b/.test(message)) return "AUTH";
    if (isQuotaExceededError(message)) return QUOTA_EXCEEDED_CODE;
    if (/\b429\b|rate.?limit/i.test(message)) return "RATE_LIMIT";
    if (/\b413\b|failed to buffer the request body:\s*length limit exceeded|payload too large|request body too large/i.test(message)) return "INVALID_REQUEST";
    if (/\b400\b|invalid.?request/i.test(message)) return "INVALID_REQUEST";
    if (/\b5\d\d\b/.test(message)) return "SERVER";
    if (/\btime(?:d)?\s*out\b|timeout/i.test(message)) return "TIMEOUT";
    if (/stream ended (?:before|without)\b/i.test(message)) return "TRANSPORT";
    if (/\b(?:network|connection|socket|fetch)\b|\bECONN[A-Z]+\b/i.test(message)
        || /\b(?:other side closed|HTTP2 request did not get a response|WebSocket closed unexpectedly)\b/i.test(message)
        || /\bterminated\b|premature close/i.test(message)) return "TRANSPORT";
    return "PI_AI_ERROR";          // ← this bug lands here
}

For "Error Code upstream_stream_read_error: Upstream response stream was interrupted" none of the arms match
(no 4xx/5xx digits, no timeout wording, no stream ended before|without, no
network|connection|socket|fetch|ECONN*, no terminated|premature close) → catch-all PI_AI_ERROR.

③ Decision point

case "error": {
    const text = message.errorMessage ?? "pi-ai stream error";
    return { kind: "error", failure: { message: text, code: classifyPiAiError(text) } };
}

④ Retry point: a code outside the eligible set delegates

From the @deepseek-ai/dsh-llm-retry docs:

In normal mode, a failure code outside the eligible set, or an exhausted budget, delegates

Default normal-mode eligible set, observed in a live llm/retry event's policyKey:

["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]

PI_AI_ERROR ∉ that set → no retry; the turn ends.

⑤ Confirmation from the session journal

The failing step's assistant/attempt record (decoded multi-frame zstd journal):

time	record
23:06:44 / 23:07:14 / 23:07:47	three reasoning blocks opened and closed, all empty
23:08:10	block-start → tool-call (index 3)
23:08:10 → 23:10:30	argument deltas for that tool call: 3,760 chunks / ≈140,124 B, over 2 min 20 s
23:10:30	usage all zeros → finish{kind:"error", failure:{code:"PI_AI_ERROR", …}}

So: a very large tool call (≈140 KB of arguments) was cut off after 2 min 20 s, and the whole step —
including everything already streamed — was discarded.

---

Scope: more than one code is affected

Two of the three stream-error codes used by a common third-party relay family (the code text is traceable to the
open-source sub2api
project, which is how I confirmed the code is not DSH's) are misclassified:

provider code	client message	current	should be
upstream_stream_read_error	Upstream response stream was interrupted	❌ PI_AI_ERROR	TRANSPORT
upstream_http2_stream_error	Upstream HTTP/2 stream failed	❌ PI_AI_ERROR	TRANSPORT
upstream_stream_truncated	Upstream response stream ended before completion	✅ TRANSPORT (regex happens to match stream ended before)	TRANSPORT

The third one only classifies correctly by textual coincidence.

---

Impact

1. A transient upstream/relay hiccup becomes a whole-turn failure for any pi-ai route
   (openai-responses and friends), instead of retrying like other transport errors.
2. Long generations are silently lost: ~140 KB of tool-call arguments in this instance, with no user-visible notice.
3. PI_AI_ERROR becomes a catch-all, so "genuinely unknown" and "upstream stream interrupted" are
   indistinguishable in journals/telemetry.
4. It contradicts DSH's own documented principle ("route on the code, never on message text").

---

Suggested fix

P0 — minimal regex patch

  if (/stream ended (?:before|without)\b/i.test(message)) return "TRANSPORT";
+ if (/\bstream (?:was )?interrupted\b/i.test(message)
+     || /upstream_stream_(?:read_error|truncated|http2_error)\b/i.test(message)
+     || /HTTP\/2 stream failed/i.test(message)) return "TRANSPORT";

Verified by replicating the original function:

PI_AI_ERROR     -> TRANSPORT        upstream_stream_read_error: Upstream response stream was interrupted
PI_AI_ERROR     -> TRANSPORT        upstream_http2_stream_error: Upstream HTTP/2 stream failed
TRANSPORT       -> TRANSPORT        upstream_stream_truncated: Upstream response stream ended before completion
INVALID_REQUEST -> INVALID_REQUEST  invalid_request_error: bad payload   ← no collateral damage

Retrying TRANSPORT here is safe: dsh-llm-retry recovers at the agent loop's agent/request-error
waterfall (open-step boundary), re-running the failed step in the same turn, and failed partial output
never reaches the model or derived messages.

P1 — let the stable code through (preferred, structural)

1. Add an optional providerCode?: string to LlmFailure.

2. Make the throw site carry it:

   - throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");
   + throw new LlmError(event.message ?? "Unknown error", "PI_AI_ERROR", { providerCode: event.code });

3. Change the classifier to classifyPiAiError(text, providerCode?): map the provider code first,
   regex only as fallback.

4. Do the same for other adapters (Anthropic / Gemini / OpenAI-compatible) so their stable codes
   map into the DSH taxonomy.

P2 — catch-all must stay diagnosable

Keep the provider's original code (and a truncated message) on the failure, and show both the DSH code
and the provider code in the UI error row, so a PI_AI_ERROR never means "unknown origin".

P3 — visibility of abandoned partial work

When a step fails mid-stream and already-streamed output is dropped, say so ("attempt abandoned,
≈N KB of streamed output discarded") instead of showing only an error code.

---

Notes / non-bugs

• The interruption itself is not a DSH defect: upstream_stream_read_error is produced by the relay when
  its own upstream SSE read fails. DSH cannot prevent it — this report is only about how DSH handles it.
• Retries are billed provider requests; keeping normal mode (bounded, with backoff) is the right default.
• Please don't try to salvage half a tool call; the ask is only (a) correct classification so the step retries,
  (b) the provider code preserved, (c) visibility when partial output is discarded.

---

Evidence appendix

Decoding the multi-frame zstd session journal

session.v4.jsonl.zstd is appended frame-by-frame, and zstdDecompressSync / createZstdDecompress
only decode the first frame. Walk the frames by magic 0xFD2FB528:

const zlib = require('zlib'), fs = require('fs');
function decode(file) {
  const buf = fs.readFileSync(file);
  const magic = Buffer.from([0x28, 0xb5, 0x2f, 0xfd]);   // LE 0xFD2FB528
  const starts = [];
  for (let i = 0; (i = buf.indexOf(magic, i)) !== -1; i++) starts.push(i);
  const out = []; let i = 0;
  while (i < starts.length) {
    let done = false;
    for (let j = i + 1; j <= starts.length; j++) {         // grow until a frame decodes
      const end = j < starts.length ? starts[j] : buf.length;
      try { out.push(zlib.zstdDecompressSync(buf.subarray(starts[i], end))); i = j; done = true; break; }
      catch (e) { /* false magic; merge into the next span */ }
    }
    if (!done) break;
  }
  return Buffer.concat(out).toString('utf8').split('\n').filter(Boolean);
}

Facts and how each was verified

fact	how
UI/message format Error Code <code>: <message>	grep -ao 'throw new Error(...)' app.asar (the event.type === "error" arm of the openai-responses stream)
classifyPiAiError table and catch-all	region around grep -ac 'classifyPiAiError' hits in strings -a app.asar
default eligible set	policyKey of a live llm/retry event (value above)
PI_AI_ERROR is not retryable	@deepseek-ai/dsh-llm-retry docs, "Failures and recovery"
the code is not from DSH	grep -ac 'upstream_stream_read_error' app.asar → 0
where the code comes from	open-source sub2api (upstream_stream_read_error / upstream_http2_stream_error / upstream_stream_truncated)

Minimum repro requirements: a api: openai-responses pi-ai route + a mid-stream
{"type":"error","code":"upstream_stream_read_error", …} frame (a fake server is enough).

[PerryLink]

你的定位我核到了根上：分类器只收一个字符串，所以 provider 的稳定错误码在结构上就被丢掉了

1. 关键的一行签名

packages/llm/llm-pi-ai/src/stream.ts:42：

function classifyPiAiError(message: string): string {

⇒ 它只接收 message: string。也就是说：只有"恰好出现在文本里"的信息才可能被用上；而 provider 通过结构化字段给的稳定错误码（你举的 upstream_stream_read_error），根本传不进这个函数 —— 于是落到末尾兜底 return 'PI_AI_ERROR'，而它不在可重试集合里 ⇒ 一次上游流中断变成不可重试的失败。

这不是"正则写得不够全"，而是"接口形状决定了只能靠文本猜"。建议在报告里就这样写——它把这条从"请补一个正则"提升为接口层缺陷，可采纳度完全不同。

2. 这已经是本周第二条同因报告

同一形态我上一轮刚答复过一条（#8722：Codex 的 WebSocket closed 1012 因措辞不符而落兜底 PI_AI_ERROR，导致不重试）。⇒ 两条合起来说明：这套分类既有"漏"（该重试的不重试）也有"误"（不该归 AUTH 的归了 AUTH，见 #7799），共同根源都是用文本代替结构化信息。

建议你在正文里引用这两条，并把诉求写成：把结构化错误信息（provider code / cause / 状态码）接进分类，文本匹配只作兜底。这比单条报告更容易被一次修掉。

3. 请补两样

1. 那个 SSE error 帧的原文（含字段名，例如 code/type 的确切形状）——它决定"要接哪一个字段"；
2. 版本：你写桌面 0.2.0-rc.2；⚠️ 当前最新是 0.2.1-alpha.1，请确认 classifyPiAiError 的签名在新版是否仍只收字符串。我核到的是是（stream.ts:42）。

4. 关于"可复现"

你这条的复现不依赖真实断线：只要构造一个带该 error 帧的流，或直接断言 classifyPiAiError('…upstream_stream_read_error…') 的返回值即可。⇒ 建议把它写成一行可跑的判据（例如"输入这段文本 ⇒ 期望 TRANSPORT，实际 PI_AI_ERROR"），维护者一条命令就能确认。这比"我遇到过一次断线"强得多。

一条边界

我确认的是分类器签名只收 message: string（由此可推出稳定错误码在构造上被丢弃）。**"该 provider 确实提供了那个码、且它是可重试的临时错误"**以你的实测为准——我没有该 provider 的流样本。

[rtsketo]

Adding a confirmed Windows reproduction of this defect, including its effect on active goals.
Environment: DSH/dsh-llm-pi-ai/dsh-goal-round-driver 0.2.0-rc.2; pi-ai 0.87.1; openai SDK 6.40.0; OpenAI-compatible Responses SSE.
This report does not attribute upstream disconnects or a 900-second cutoff to DSH.

Observed behavior

Ten fatal turns: eight disconnects and two explicit provider overloads. None retried; other TIMEOUT/TRANSPORT failures in the same deployment did retry.
Both messages below classify as PI_AI_ERROR. Last substantive stream activity was within 152 seconds of every fatal failure, not the 300-second idle timeout.
The retry-policy bypass leads to agent/error, which disarms automatic goal continuation; the durable goal can still appear active while no work continues.

Minimal offline reproduction

Pass this JavaScript on stdin to node --input-type=module -; substitute the installation path. No network, credentials, or plugin import:

const { readFileSync } = await import('node:fs');
const R = '<DSH install>/node_modules/';
const src = readFileSync(R + '@deepseek-ai/dsh-llm-pi-ai/lib/index.js', 'utf8');
const body = src.split('\n').slice(1379, 1391).join('\n');
const classify = new Function('isQuotaExceededError', 'QUOTA_EXCEEDED_CODE', body + '\nreturn classifyPiAiError;')(() => false, 'QUOTA_EXCEEDED');
console.log(classify('stream error: stream disconnected before completion: stream closed before response.completed'));
console.log(classify('Our servers are currently overloaded. Please try again later.'));

Actual: PI_AI_ERROR twice. Expected: TRANSPORT and transient SERVER/overload, eligible for bounded retries. The real quota guard also returns false for both texts.

Verified installed-source boundary

@deepseek-ai/dsh-llm-pi-ai/lib/index.js:1380-1391,1445-1452: text-only classification misses both messages.
openai/core/streaming.mjs:35-48: SSE data.error becomes APIError with undefined top-level HTTP status; the nested error body is retained.
@earendil-works/pi-ai/dist/utils/error-body.js:36-45,111-117 and dist/api/openai-responses.js:153-155: nested status is not recovered into classification; formatted text reaches the adapter.
@deepseek-ai/dsh-llm/lib/index.js:251-257: default transient codes exclude PI_AI_ERROR.
@deepseek-ai/dsh-goal-round-driver/lib/index.js:201-202: agent/error disarms continuation.
Please preserve structured provider classification, add narrow regressions for these messages, and retry at a safe model-request boundary without replaying completed tools.
Do not blanket-retry PI_AI_ERROR. The overload wording also relates to #3407; gateway interruption wording relates to #8743.

[rtsketo]

已更新 fork 补丁：补齐中继错误码、裸词 overloaded 和 WebSocket 断流

@Matthew-Laplace 谢谢你的独立复测。我已按这些用例扩展原补丁；仍采用窄化分类，而不是把 PI_AI_ERROR 整体加入可重试集合。

• 完整补丁（包含原提交和本次后续提交）：https://github.com/rtsketo/deepseek-harness/compare/5badb15009ae1756c3afe0ae0cef1faafc290ccc...a844e6e9697f6f84e0479b71f867a8f836939b5e.patch
• 后续提交：rtsketo@a844e6e
• 分支：https://github.com/rtsketo/deepseek-harness/tree/stream-retry-codes
• 基线：5badb15009ae1756c3afe0ae0cef1faafc290ccc（0.2.1-alpha.1）；原提交 c8ff3afefc3ba624118bdcff006f709936a404e6 保留，未改写已发布历史。

输入	更新后的分类
stream error: stream disconnected before completion: stream closed before response.completed	TRANSPORT
Our servers are currently overloaded. Please try again later.（含 Codex 前缀）	SERVER
overloaded	SERVER
Error Code upstream_stream_read_error: Upstream response stream was interrupted	TRANSPORT
Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed	TRANSPORT
upstream_stream_truncated（不依赖描述措辞）	TRANSPORT
WebSocket stream closed before response.completed	TRANSPORT
WebSocket closed 1012（可带原因后缀）	TRANSPORT

有一处拼写需要区分：实际中继码是 upstream_http2_stream_error，不是建议正则里的 upstream_stream_http2_error。补丁匹配的是前者，且限制完整标识符，避免误匹配带额外前后缀的未知错误码。

我没有直接使用 /websocket/i。当前 pi-ai 还会产生 Invalid Codex WebSocket JSON: ...、1008 策略失败和 1009 消息过大等错误；仅凭出现 WebSocket 就重试会过宽。因此保留现有 WebSocket closed unexpectedly，只补上已确认的完成前关闭和 1012 情形。认证、配额、限流、非法请求及现有超时分类的优先级不变；原始失败文本也不改写。

验证结果：

• 在原 fork 补丁上运行新增回归，出现 16 个预期失败；更新后，分类、实际 pi-ai/OpenAI SDK 的 mock HTTP-200 Responses SSE 转换和重试测试共 218 个通过。stream.ts 的 statements、branches、functions、lines 均为 100%。
• SSE 测试覆盖顶层 {type: 'error', code, message, param, sequence_number} 帧，而不只覆盖嵌套 error 对象。upstream_stream_truncated 用例故意采用不匹配旧规则的描述，验证分类确实来自错误码文本。
• 既有重试测试仍验证：完成过的工具不会重新执行，未知 PI_AI_ERROR 不会重试。永久错误和错误码前后缀等负对照通过。
• keyless headless 场景的 built-profile refresh 和只读 replay 均通过，另有 3 个录制会话 corpus 检查通过。首轮 built-profile 检查因 Client 阶段构建产物不完整而失败；完成正常 Client 构建后通过，未修改或放宽断言。
• 完整 lint：5,169 个文件，0 warnings / 0 errors。Host / Client 库构建和完整 doc-sync 均通过：42 项通过，0 失败，0 跳过。构建配置加载使用命令级 tsx/esm，未修改持久环境或源代码来修补测试环境。
• 正常 pre-commit / pre-push 均通过，包括 pnpm run typecheck；未绕过任何 hook。

范围仍是文本分类兜底：DSH 在这里收到的是 pi-ai 的 errorMessage 字符串。补丁没有恢复结构化 provider code，也没有修改第三方 pi-ai、默认重试集合、goal driver、agent loop、持久化或依赖。它修复上述文本进入既有有界重试路径的问题，不消除上游断流或服务端时限，也不声称覆盖所有提供方错误。

未修改或部署任何已安装运行时；未向上游创建 PR。

[Matthew-Laplace]

补充数据（原发帖人）：你提的两条判据都已在 0.2.0-rc.2 上实测，另有一条更靠上的新发现会改变修复方案。

---

0. 结论先行

1. rtsketo 的离线判据在本机复现：两条输入都是 PI_AI_ERROR（下面有逐字命令与输出）。
2. 新发现（会改变 P1 方案）：抛错点不在 DSH 的 adapter，而在被 vendored 的第三方库 @earendil-works/pi-ai —— dist/api/openai-responses-shared.js:640-641。DSH 侧只拿到一个字符串（message.errorMessage）。所以「给 LlmFailure 加 providerCode」如果不改 pi-ai（或改用别的取值路径），是补不上的。
3. 帧的字段名可证的部分：type / code / message。原始 wire 字节没有被持久化（DSH 不保存 SSE 原文），所以下面是「代码可证 + 日志可证」的最强版本，不是我编的原文。
4. 版本：dsh-llm-pi-ai 的 lib/index.js 在 0.2.1-alpha.1 与本机 0.2.0-rc.2 字节相同（md5 1858e6f63125e8982528e7a0cdb70ebc）→ 未修。

---

1. rtsketo 的判据：本机复现（逐字）

$ node --input-type=module - <<'EOF'
const { readFileSync } = await import('node:fs');
const R = '<npm-global>/@deepseek-ai/dsh/node_modules/';
const src = readFileSync(R + '@deepseek-ai/dsh-llm-pi-ai/lib/index.js', 'utf8');
const body = src.split('\n').slice(1379, 1391).join('\n');
const classify = new Function('isQuotaExceededError', 'QUOTA_EXCEEDED_CODE',
  body + '\nreturn classifyPiAiError;')(() => false, 'QUOTA_EXCEEDED');
console.log(classify('stream error: stream disconnected before completion: stream closed before response.completed'));
console.log(classify('Our servers are currently overloaded. Please try again later.'));
EOF
PI_AI_ERROR
PI_AI_ERROR

你的行号切片（1379-1391）与安装包完全吻合：classifyPiAiError 定义在 lib/index.js:1380-1391。

2. 分类矩阵（20 条，全部真实字符串）

我在同一条路径上又跑了 18 条（同一函数、同一安装包），把边界钉死：

输入	返回	备注
Error Code upstream_stream_read_error: Upstream response stream was interrupted	PI_AI_ERROR	❌ 应为 TRANSPORT
Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed	PI_AI_ERROR	❌ 应为 TRANSPORT
Error Code upstream_stream_truncated: Upstream response stream ended before completion	TRANSPORT	✅ 只因命中 /stream ended (?:before|without)/
stream error: stream disconnected before completion: stream closed before response.completed	PI_AI_ERROR	❌ rtsketo 的第 1 条
Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	❌ rtsketo 的第 2 条（503 才命中，措辞不命中）
503 Service Unavailable	SERVER	对照：有状态码就走对
429 Too Many Requests	RATE_LIMIT
401 Unauthorized / Your quota has been exceeded	AUTH / QUOTA_EXCEEDED
invalid_request_error: bad payload	INVALID_REQUEST
socket hang up / ECONNRESET / fetch failed / terminated / premature close	TRANSPORT
HTTP2 request did not get a response / WebSocket closed unexpectedly / other side closed	TRANSPORT
The operation was aborted due to timeout	TIMEOUT
stream ended without a completed response	TRANSPORT

这条矩阵本身就是"窄回归"的清单：前两条 + rtsketo 的两条应该各自有固定期望值。

3. 你要的「SSE error 帧原文（含字段名）」

3.1 代码可证的部分

抛错臂（vendored pi-ai，dist/api/openai-responses-shared.js:640-641）：

else if (event.type === "error") {
    throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");
}

⇒ 该臂读的是 event.type、event.code、event.message；我们看到的渲染文本 Error Code upstream_stream_read_error: Upstream response stream was interrupted 证明这三个字段在当时都取到了值。因此该帧至少是：

{ "type": "error", "code": "upstream_stream_read_error", "message": "Upstream response stream was interrupted" }

（这是"能证明存在这三个字段"，不是"我抓到了 wire 原文"。）

3.2 日志可证的部分（DSH 只留下文本，没有 code）

原始记录（turn/end，2026-10-04T15:10:30Z，turn=7 step=19，逐字）：

{"turn":7,"reason":{"kind":"error","error":{"message":"Error Code upstream_stream_read_error: Upstream response stream was interrupted","code":"PI_AI_ERROR"}}}

注意 error.code 是 DSH 自己的 PI_AI_ERROR；整条记录里没有 provider code 字段——provider 的 code 只活在 message 文本里。同一时刻的 assistant/attempt（turn=7 step=19）也在日志里，即被丢弃的那一步。

3.3 一条推断（已标注）

持久化的文本里没有出现 "<provider> API error (<status>): ..." 这类前缀。而 pi-ai 的组装逻辑是 openai-responses.js:154：

output.errorMessage = formatProviderError(normalizeProviderError(error), `${model.provider === "openai" ? "OpenAI" : model.provider} API error`);

formatProviderError（dist/utils/error-body.js:111-117）在 status === undefined || body === undefined 时原样返回 message、丢掉前缀。⇒ 推断：该 error 对象上没有 extractStatus() 认识的状态字段（statusCode / status / $metadata.httpStatusCode / $response.statusCode，见 error-body.js:37-47），即 HTTP status 在这一层是 undefined。这与 rtsketo 的 undefined top-level HTTP status 一致，但请按推断看待。

3.4 诚实边界

本机没有代理/HTTP 层抓包日志，DSH 也不持久化原始 SSE 帧，所以我没法给出 byte 级原文。如果你的 relay 侧有 access log，那个才是权威原文。

4. 新发现：抛错点在 pi-ai，不在 DSH adapter（影响修复方案）

层	位置	事实
vendored pi-ai	@earendil-works/pi-ai/dist/api/openai-responses-shared.js:640-641	结构化 code 在这里被降级成字符串
DSH adapter	@deepseek-ai/dsh-llm-pi-ai/lib/index.js:1445-1452	只拿到 message.errorMessage，再交给 classifyPiAiError(text)

case "error": {
    const text = message.errorMessage ?? "pi-ai stream error";
    return { kind: "error", failure: { message: text, code: classifyPiAiError(text) } };
}

⇒ 原帖 P1 的"给 LlmFailure 加 providerCode 并让 throw site 带上它"落点不够：throw site 在第三方库里，DSH 的 adapter 根本没机会看到 event.code。可行的方向有三类，建议在正文里明确写成选项：
(a) 上游 pi-ai 在 error 对象上保留 code（结构性、最干净，但依赖上游）；
(b) DSH 的 pi-ai adapter 改走能拿到结构化字段的路径（而不是只看 errorMessage）；
(c) 现状下的最小补救仍是正则窄化（你已给的 P0）——但请注明它是权宜。

grep -c 'Error Code' @deepseek-ai/dsh-llm-pi-ai/lib/index.js = 0，可自行复核这一点。

5. 你的 undefined status 说法：Chat Completions 路径也复核了

openai/core/streaming.mjs:45-47：

if (data && data.error) {
    throw new APIError(undefined, data.error, undefined, response.headers);
}

第一个参数（HTTP status）就是 undefined，第四个才是 headers ⇒ 嵌套 data.error 被完整保留、但顶层 status 缺失，与你描述一致。

6. 重试集合与 goal 影响（逐条复核）

• 默认可重试集合：@deepseek-ai/dsh-llm/lib/index.js:251-257

  const DEFAULT_RETRYABLE_CODES = Object.freeze([
      EMPTY_RESPONSE_CODE, "RATE_LIMIT", "SERVER", "TIMEOUT", "TRANSPORT"
  ]);

  PI_AI_ERROR 不在其中（确认）。
• goal 影响（rtsketo 的说法成立）：@deepseek-ai/dsh-goal-round-driver/lib/index.js:200-203

  ctx.on("agent/error", ({ agent }) => { disarm(stateFor(agent)); });

  ⇒ agent/error 会 disarm 该 agent 的 goal 状态。

7. 版本口径（更正一处）

项	值
本机 DSH	0.2.0-rc.2
@deepseek-ai/dsh-llm-pi-ai@0.2.1-alpha.1 vs 本机	md5 相同 1858e6f63125e8982528e7a0cdb70ebc → classifyPiAiError 逐字相同
npm dist-tags	latest = 0.2.0-rc.2、next = 0.2.0-rc.2、alpha = 0.2.1-alpha.1

⇒ 请把"请确认新版是否仍复现"写成"alpha 通道"，并可直接引用上面的 md5 —— alpha 上仍未修。

8. 给 rtsketo 的 narrow regressions（可直接抄）

classifyPiAiError('stream error: stream disconnected before completion: stream closed before response.completed')
    expected TRANSPORT (currently PI_AI_ERROR)
classifyPiAiError('Our servers are currently overloaded. Please try again later.')
    expected SERVER (currently PI_AI_ERROR)
classifyPiAiError('Error Code upstream_stream_read_error: Upstream response stream was interrupted')
    expected TRANSPORT (currently PI_AI_ERROR)
classifyPiAiError('Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed')
    expected TRANSPORT (currently PI_AI_ERROR)

负面回归（不要被顺手改坏）：'invalid_request_error: bad payload' 必须仍然是 INVALID_REQUEST；'401 Unauthorized' 必须仍是 AUTH。

9. 关于「不要 blanket-retry PI_AI_ERROR」——同意

PI_AI_ERROR 是 catch-all（lib/index.js:1390 的 return "PI_AI_ERROR"），它同时承载"上游流中断"和"真正未知的 pi 适配器错误"。把它整体加入可重试集合，等于把未知错误也重试。正确做法是先窄化分类（第 8 节），再让 TRANSPORT 走既有重试路径。原帖"重试发生在 open-step 边界、失败的部分输出不会进入模型"这一条我未独立验证，请在正文里标注为原帖主张。

---

English summary for @rtsketo

1. Your offline reproduction is confirmed on DSH 0.2.0-rc.2 (exact output in §1): both strings return PI_AI_ERROR.
2. New, load-bearing finding: the throwing site is not in DSH's adapter but in the vendored third-party library — @earendil-works/pi-ai/dist/api/openai-responses-shared.js:640-641. DSH only receives message.errorMessage (a string) at @deepseek-ai/dsh-llm-pi-ai/lib/index.js:1445-1452. So preserving structured provider classification requires a change in pi-ai (or a different read path in the adapter); adding providerCode to LlmFailure alone cannot work.
3. Frame fields: the throwing arm reads event.type / event.code / event.message; the persisted journal contains only {message, code:"PI_AI_ERROR"} and no provider code field. Raw wire bytes are not persisted by DSH — we cannot supply a captured frame, and we will not invent one.
4. Your undefined top-level HTTP status claim is corroborated: openai/core/streaming.mjs:45-47 throws new APIError(undefined, data.error, undefined, response.headers), and formatProviderError (error-body.js:111-117) drops its prefix when status/body are undefined — matching the prefix-less text we observe.
5. Goal impact confirmed: @deepseek-ai/dsh-goal-round-driver/lib/index.js:200-203 disarms on agent/error. Default retryable set is @deepseek-ai/dsh-llm/lib/index.js:251-257 (EMPTY_RESPONSE/RATE_LIMIT/SERVER/TIMEOUT/TRANSPORT).
6. Agreed: no blanket-retrying of PI_AI_ERROR. Narrow the classification first (§8 gives the exact regression strings), then let TRANSPORT use the existing retry path.
7. Version: dsh-llm-pi-ai is byte-identical between 0.2.0-rc.2 and 0.2.1-alpha.1 (md5 1858e6f6…) — not fixed in the alpha channel.

[Matthew-Laplace]

追加（同一位发帖人）：三条补充，其中第 2 条直接解释你提到的 #8722。

1. 帧的字段集——可以再精确一格

除我上一条给的「type / code / message 由抛错臂可证」之外，SDK 自己的类型声明给出了完整字段集：openai/resources/responses/responses.d.ts:1976-1997

export interface ResponseErrorEvent {
    code: string | null;            // :1980
    message: string;                // :1984
    param: string | null;           // :1988
    sequence_number: number;        // :1992
    type: 'error';                  // :1996
}

即帧是 {"type":"error","code":…,"message":…,"param":…,"sequence_number":…}。其中 type/code/message 有实测证据（渲染文本逐字吻合），param/sequence_number 是类型声明有、但没有任何捕获样本——上面已经区分标注。

另外更正一种常见猜测：{"type":"error","error":{…},"sequence_number":…} 这种嵌套形状不会产生我们观测到的文本。嵌套形状会被 SDK 在 openai/core/streaming.mjs:45-46 拦下并变成 APIError(undefined, data.error, …)，其 message 只取 error.message（openai/core/error.mjs:17-23）⇒ 渲染出来是裸的 Upstream response stream was interrupted，没有 Error Code 前缀。我们捕获到的是带前缀的那个 ⇒ 实际帧是扁平形状 {type, code, message}。

2. 两个决定性的 near-miss（其中一个就是 #8722 的机制）

输入	返回	说明
overloaded	PI_AI_ERROR	而 pi-ai 自己的 SDK 重试列表里有它：@earendil-works/pi-ai/dist/utils/retry.js:22 "overloaded",。即上游认为可重试，DSH 分类器认不出。
WebSocket stream closed before response.completed	PI_AI_ERROR	原因很具体：:1389 的 \bsocket\b 匹配不到 WebSocket 里面（b 与 S 之间没有单词边界），而该行的显式备选是精确串 WebSocket closed unexpectedly。
stream ended without message_stop	TRANSPORT	对照：命中 :1388 的 stream ended (?:before|without)
OpenAI Responses stream ended before a terminal response event	TRANSPORT	同上，巧合命中

⇒ 你提到的 #8722（Codex 的 WebSocket closed 1012 落兜底） 和本条的根因是同一个：分类器用 \bsocket\b 想覆盖 socket 类错误，但 WebSocket 里没有那个词边界，于是只剩一个精确串兜着。建议把 #8722 与本条并成一条修：给 :1389 补 /websocket/i 与 /overloaded/i，而不是只补 upstream_stream_*。

（第一、二行的字符串来源："overloaded" 见 pi-ai 的 utils/retry.js:22；"WebSocket stream closed before response.completed" 见 @earendil-works/pi-ai/dist/api/openai-codex-responses.js:1095。都不是我编的。）

3. 你的判据可复现性的一处提醒 + 结论落点

• 提醒（不是问题，只是方便别人复跑）：按字面引用 lines 1379-1391 切出来的代码跑不出 PI_AI_ERROR——:1379 是上一个函数的收尾 }（整体包进 new Function 会 SyntaxError），且 classifyPiAiError 依赖模块作用域的 isQuotaExceededError / QUOTA_EXCEEDED_CODE（dsh-llm/lib/index.js:138、:181-183），不注入就会对任何输入抛 ReferenceError。我复现时是把这两个 helper 一起注入的（new Function('isQuotaExceededError','QUOTA_EXCEEDED_CODE', body + 'return classifyPiAiError;')(…)），结果才得到你预期的两条 PI_AI_ERROR。你的结论成立，只是切片需从 1380 开始并且要注入 helper。
• 丢在哪一行（确切的 retry 落点）：@deepseek-ai/dsh-llm-retry/lib/index.js:160

  } else if (!policy.retryableCodes.includes(failure.code)) return next();

  PI_AI_ERROR 不在 DEFAULT_RETRYABLE_CODES（dsh-llm/lib/index.js:251-257）⇒ 直接 next()，不重试。
• 同会话 A/B（真实日志）：同一次会话里只有两个错误 turn ——
  • TRANSPORT（DeepSeek Messages transport failed）：重试 5 次，其 llm/retry 事件里 policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]；
  • 本条 PI_AI_ERROR：llm/retry / llm/retry-started 0 次。
    这让「不是重试器坏了，是分类错了」这句话有了同会话内的对照证据。
• goal 断链的完整落点：@deepseek-ai/dsh-agent-loop/lib/index.js:880 发 agent/error → @deepseek-ai/dsh-goal-round-driver/lib/index.js:201-202 disarm(stateFor(agent)) → @deepseek-ai/dsh-goal/lib/index.js:624 setActivation(agent.session, "disarmed")。即你观察到的「goal 看着还在 active 但不再推进」在代码上成立。
• alpha 复核：dsh-llm 在 0.2.1-alpha.1 与 0.2.0-rc.2 的差异是 3 处（2 处文档注释 + 1 处 INVARIANT 记账删除），DEFAULT_RETRYABLE_CODES 区块逐字相同，dsh-llm-pi-ai/lib/index.js 整体 SHA-256 相同（d46dbc30aeb3414190000e6f8aeaaf994246b5e5c651de07639f4a7e92de37ef）⇒ 未修。

[Matthew-Laplace]

Supplementary data (original reporter) — English version

English consolidation of my two earlier comments. All commands were run against the installed 0.2.0-rc.2 tree; nothing here is inferred without being labelled.

---

1. Your offline reproduction is confirmed on 0.2.0-rc.2

Your procedure, run against the installed package (with the module-scope helpers supplied, see §7):

$ node --input-type=module - <<'EOF'
const { readFileSync } = await import('node:fs');
const R = '<npm-global>/@deepseek-ai/dsh/node_modules/';
const src = readFileSync(R + '@deepseek-ai/dsh-llm-pi-ai/lib/index.js', 'utf8');
const body = src.split('\n').slice(1379, 1391).join('\n');
const classify = new Function('isQuotaExceededError', 'QUOTA_EXCEEDED_CODE',
  body + '\nreturn classifyPiAiError;')(() => false, 'QUOTA_EXCEEDED');
console.log(classify('stream error: stream disconnected before completion: stream closed before response.completed'));
console.log(classify('Our servers are currently overloaded. Please try again later.'));
EOF
PI_AI_ERROR
PI_AI_ERROR

classifyPiAiError is dsh-llm-pi-ai/lib/index.js:1380-1391, one string parameter, identical to what you cited.

2. Classification matrix (20 strings, all sourced — none invented)

Input	Returned	Note
Error Code upstream_stream_read_error: Upstream response stream was interrupted	PI_AI_ERROR	should be TRANSPORT
Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed	PI_AI_ERROR	should be TRANSPORT
Error Code upstream_stream_truncated: Upstream response stream ended before completion	TRANSPORT	only by textual coincidence
stream error: stream disconnected before completion: stream closed before response.completed	PI_AI_ERROR	your string #1
Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	your string #2
overloaded	PI_AI_ERROR	see §6 — pi-ai's own retry list contains it
WebSocket stream closed before response.completed	PI_AI_ERROR	see §6 — this is the #8722 mechanism
503 Service Unavailable	SERVER	control: a real status code routes correctly
500 Internal Server Error	SERVER
429 Too Many Requests / Error Code 429: too many requests	RATE_LIMIT
401 Unauthorized / OpenAI API error (401): Incorrect API key provided	AUTH
insufficient quota	QUOTA
invalid_request_error: bad payload	INVALID_REQUEST	negative control — must stay
socket hang up / terminated / fetch failed / read ECONNRESET	TRANSPORT
HTTP2 request did not get a response / other side closed	TRANSPORT
stream ended without message_stop / OpenAI Responses stream ended before a terminal response event	TRANSPORT
pi-ai stream idle timeout after 300000ms	TIMEOUT

Sources for the strings (so the matrix is reproducible): @earendil-works/pi-ai/dist/utils/retry.js:22 ("overloaded"), :48 "fetch failed", :54 "socket hang up", :58 "terminated", :66 "stream ended before message_stop"; pi-ai/dist/api/openai-codex-responses.js:1095 ("WebSocket stream closed before response.completed"); pi-ai/dist/api/openai-responses-shared.js:657; dsh-llm-pi-ai/lib/index.js:1910 (idle-timeout template); upstream_* codes and their messages come from the gateway's own Go constants (quoted third-party source, not observed frames).

3. The SSE error frame — what can and cannot be established

Code-backed field set. The throwing arm reads event.type / event.code / event.message — @earendil-works/pi-ai/dist/api/openai-responses-shared.js:640-641:

else if (event.type === "error") {
    throw new Error(`Error Code ${event.code}: ${event.message}` || "Unknown error");
}

The SDK's own declaration for that event gives the full field list — openai/resources/responses/responses.d.ts:1976-1997:

export interface ResponseErrorEvent {
    code: string | null;      // :1980
    message: string;          // :1984
    param: string | null;     // :1988
    sequence_number: number;  // :1992
    type: 'error';            // :1996
}

⇒ the frame is {"type":"error","code":…,"message":…,"param":…,"sequence_number":…}. type/code/message are proven by the captured message text; param/sequence_number are declared-not-observed — no session log stores raw SSE bytes, so I will not present them as captured.

A shape that cannot have produced our message. A frame of the form {"type":"error","error":{…},"sequence_number":…} is intercepted earlier by the SDK at openai/core/streaming.mjs:45-46 and becomes new APIError(undefined, data.error, undefined, response.headers); APIError.makeMessage then uses only error.message (openai/core/error.mjs:17-23). That would surface as the bare string Upstream response stream was interrupted — without the Error Code prefix. Our capture has the prefix ⇒ the observed frame was the flat {type, code, message} form.

What DSH persisted. turn/end in the failing session, verbatim:

{"turn":7,"reason":{"kind":"error","error":{"message":"Error Code upstream_stream_read_error: Upstream response stream was interrupted","code":"PI_AI_ERROR"}}}

error.code is DSH's own PI_AI_ERROR; there is no provider-code field anywhere in the record — the provider's stable code survives only as a substring of message. Corresponding assistant/attempt (same turn/step) is in the same journal. A same-session control turn reads {"kind":"error","error":{"message":"DeepSeek Messages transport failed","code":"TRANSPORT"}}.

4. Precision fix: the throwing site is in the vendored pi-ai, not in DSH's adapter

Layer	Location	Fact
vendored pi-ai	@earendil-works/pi-ai/dist/api/openai-responses-shared.js:641	interpolates event.code into a plain Error message
pi-ai Responses path	dist/api/openai-responses.js:154	output.errorMessage = formatProviderError(normalizeProviderError(error), …)
DSH adapter	@deepseek-ai/dsh-llm-pi-ai/lib/index.js:1445-1452	only message.errorMessage (a string) reaches the classifier

case "error": {
    const text = message.errorMessage ?? "pi-ai stream error";
    return { kind: "error", failure: { message: text, code: classifyPiAiError(text) } };
}

pi-ai declares it string-only: @earendil-works/pi-ai/dist/types.d.ts:367 errorMessage?: string; — there is no structured errorCode field. grep -c 'Error Code' @deepseek-ai/dsh-llm-pi-ai/lib/index.js → 0.

⇒ The original report's P1 ("add providerCode to LlmFailure and carry it at the throw site") cannot work as written. The throw site is in a third-party library and the adapter never sees event.code. Options: (a) upstream pi-ai preserves code on the error object; (b) DSH's adapter takes a path that yields structured fields instead of only errorMessage; (c) the minimal regex narrowing (P0) remains a stopgap — worth labelling as such.

Precision fix on the claim itself: "a structured provider error code never reaches the classifier" is imprecise. The code does reach it — as unstructured text. What never reaches it is the field.

5. SDK paths: your undefined status claim is corroborated

openai/core/streaming.mjs:45-47 (openai 6.40.0):

if (data && data.error) {
    throw new APIError(undefined, data.error, undefined, response.headers);
}

The status argument is undefined; the nested data.error survives as err.error/code/param/type (openai/core/error.mjs:5-16), while err.status stays undefined. pi-ai's extractStatus (dist/utils/error-body.js:36-46) probes only statusCode → status → $metadata.httpStatusCode → $response.statusCode, never a nested error object, so it returns undefined; formatProviderError (:111-118) then returns norm.message and drops the provider prefix. Inference from that: the prefix-less text we observe implies no recognizable status/body was recovered on that error object.

For completeness on the other streaming API: the Chat-Completions path flattens the nested status the same way, so neither API recovers it into the classification.

6. Two decisive near-misses (one of them is #8722)

• overloaded → PI_AI_ERROR, even though pi-ai's own SDK retry list contains "overloaded" (pi-ai/dist/utils/retry.js:22). Upstream considers it retryable; DSH's classifier cannot recognize it.
• WebSocket stream closed before response.completed → PI_AI_ERROR, for a very specific reason: dsh-llm-pi-ai/lib/index.js:1389 matches \bsocket\b, which cannot match inside WebSocket (no word boundary between b and S), and its explicit alternative is the exact string WebSocket closed unexpectedly. So the socket family is covered only by one exact phrase.

⇒ The #8722 case (Codex WebSocket closed 1012 falling through to the catch-all) and this report share one root cause. Suggested merge: add /websocket/i and /overloaded/i at :1389 in addition to the upstream_stream_* patterns — not only the latter.

7. Reproducibility caveat (so others can re-run it)

Quoting the slice as lines 1379-1391 does not run: :1379 is the closing } of the preceding function (a bare new Function over it throws SyntaxError), and classifyPiAiError depends on module-scope bindings from @deepseek-ai/dsh-llm — QUOTA_EXCEEDED_CODE (dsh-llm/lib/index.js:138) and isQuotaExceededError (:181-183) — so without injecting them every input throws ReferenceError at :1382. Slice from 1380 and inject both helpers; then the two PI_AI_ERROR results appear. Your conclusion stands; only the harness needed the fix.

8. Retry decision and goal impact

• Exact drop point: @deepseek-ai/dsh-llm-retry/lib/index.js:160

  } else if (!policy.retryableCodes.includes(failure.code)) return next();

• Retryable set: @deepseek-ai/dsh-llm/lib/index.js:251-257 = {EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT} — PI_AI_ERROR absent (and QUOTA absent too).
• Same-session A/B in real logs: the TRANSPORT turn retried 5× with policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1], while this PI_AI_ERROR turn has zero llm/retry / llm/retry-started frames. So the retry executor works; the classification is what fails.
• Goal impact confirmed: agent/error is emitted at dsh-agent-loop/lib/index.js:880 → dsh-goal-round-driver/lib/index.js:201-202 disarm(stateFor(agent)) → dsh-goal/lib/index.js:624 setActivation(agent.session, "disarmed"). A PI_AI_ERROR turn therefore stops automatic goal continuation, which matches the "goal still looks active but no work continues" observation.

9. Version check

Package	0.2.0-rc.2 vs 0.2.1-alpha.1
@deepseek-ai/dsh-llm-pi-ai/lib/index.js	SHA-256 identical (d46dbc30aeb3414190000e6f8aeaaf994246b5e5c651de07639f4a7e92de37ef); the rc.2 tarball is bit-identical to the installed file
@deepseek-ai/dsh-llm/lib/index.js	3 hunks, none touching retry policy; DEFAULT_RETRYABLE_CODES block identical

⇒ unfixed in 0.2.1-alpha.1. (Tag note: 0.2.1-alpha.1 is on the npm alpha tag only; latest/next are 0.2.0-rc.2.)

10. Narrow regressions to add (copy-ready)

classifyPiAiError('stream error: stream disconnected before completion: stream closed before response.completed')
    expected TRANSPORT   (currently PI_AI_ERROR)
classifyPiAiError('Our servers are currently overloaded. Please try again later.')
    expected SERVER      (currently PI_AI_ERROR)
classifyPiAiError('Error Code upstream_stream_read_error: Upstream response stream was interrupted')
    expected TRANSPORT   (currently PI_AI_ERROR)
classifyPiAiError('Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed')
    expected TRANSPORT   (currently PI_AI_ERROR)
classifyPiAiError('WebSocket stream closed before response.completed')
    expected TRANSPORT   (currently PI_AI_ERROR)   ← #8722
classifyPiAiError('overloaded')
    expected SERVER      (currently PI_AI_ERROR)

Negative controls that must not change: 'invalid_request_error: bad payload' → INVALID_REQUEST; '401 Unauthorized' → AUTH.

11. Agreed: do not blanket-retry PI_AI_ERROR

PI_AI_ERROR is the catch-all (:1390), carrying both "upstream stream interrupted" and genuinely unknown pi-adapter failures. Making it retryable wholesale would retry the unknown class too. Narrow the classification first (§10), then let TRANSPORT use the existing path. The original report's claim that a retry happens at the open-step boundary and that failed partial output never reaches the model is the reporter's claim — I have not independently verified it; please label it as such if you cite it.

[PerryLink]

你这条更正改变了修复方案——我接受，并且据此把方案改成三层

1. 接受更正：抛错点不在 DSH 侧

你核到抛错在被 vendored 的第三方库 @earendil-works/pi-ai（dist/api/openai-responses-shared.js:640-641），而 DSH 侧最终只拿到一个字符串（message.errorMessage）。

⇒ 因此我上一轮那句"给 LlmFailure 加 providerCode"在 DSH 单侧做不到——它得先有那个字段能被取到。这个更正很关键，我撤回原来的说法。

2. ⇒ 修正后的方案（三层，第 3 层今天就能生效）

第 1 层·上游（治本）：在 pi-ai 的抛错臂里不要只保留 message，把 code 一并带出（你已证 code 属于该帧的可证字段集）。⇒ 这是唯一能让分类器用上结构化信息的路。建议把这条写成"需要 pi-ai 配合"的明确诉求，而不是当成 DSH 的 bug。

第 2 层·DSH 侧保留原文：你指出 DSH 不保存 SSE wire 原文 ⇒ 出错后无法事后取证。⇒ 建议在失败路径上保留原始错误帧（哪怕只在 error 分支上记一条），这样：① 分类器将来能用结构化字段；② 用户报告时不必再靠"代码可证"的最强版本。这一层完全在 DSH 手里，成本低、收益直接。

第 3 层·文本匹配兜底（今天就能修）：你说帧里有 code，且其值是稳定字符串（如 upstream_stream_read_error）。⇒ 即使它只以文本形式到达 DSH，把它加进 TRANSPORT 模式也是确定性改进：

在 classifyPiAiError 的 TRANSPORT 分支里补上已知的稳定错误码字面量（例如 upstream_stream_read_error），使这类上游流中断能命中既有的重试路径。

这一层的价值在于：它不依赖 pi-ai 改动、不依赖新的数据流，而你与 #8722 的两条报告都已经证明"落进兜底就不重试"。建议把它作为过渡方案明确写进报告——维护者可以立刻采用。

3. rtsketo 的数据把严重度显著抬高了（建议引用）

他给的现场（Windows、0.2.0-rc.2）里有三条特别硬的事实：

1. 10 次致命失败（8 次断连 + 2 次提供方过载）全部没有重试，而同一部署里其它 TIMEOUT/TRANSPORT 失败确实重试了 ⇒ 证明问题在分类，不在重试机制；
2. 最后一次流活动距失败 ≤152 秒，不是 300 秒空闲超时 ⇒ 排除"超时被误判"这一解释；
3. 重试策略被绕过 ⇒ 走到 agent/error ⇒ 正在进行的 goal 被解除武装（disarms）。

⇒ 第 3 条是这条报告真正的分量：一次本该重试的传输失败，代价不只是"这一轮失败"，而是把用户的自治目标停掉了。建议把它放在摘要里——它把"分类不准"从体验问题升级为功能被中断。

4. 你给的版本事实很有用（请保留）

dsh-llm-pi-ai/lib/index.js 在 0.2.1-alpha.1 与 0.2.0-rc.2 md5 相同（1858e6f63125e8982528e7a0cdb70ebc）⇒ 未修。这种"用字节相同证明未修"的写法比"我升级后还有"更强，建议保留。

5. 一条边界

我确认的是你的更正方向（抛错点在 vendored pi-ai、DSH 只拿到字符串）与 rtsketo 的判据在逻辑上相容，以及第 3 层方案不依赖上游改动。pi-ai 内部的取值路径以你的核对为准——我没有读那个 vendored 包。

[Matthew-Laplace]

Reply: I tested your fork patch against the relay codes in the original report — 3 of your 3 messages fixed, 4 related cases still fall through

Thanks for the patch and for sharing it as a fork (noted that upstream does not accept external PRs). I applied your two production substitutions to the installed classifier and re-ran my matrix, so here is an independent check rather than a reading of the diff.

1. What your patch fixes — confirmed, no regressions

I took classifyPiAiError verbatim from the installed @deepseek-ai/dsh-llm-pi-ai/lib/index.js:1380-1391 and applied exactly the two stream.ts changes (/\b5\d\d\b|\bour servers are currently overloaded\b/i and /stream (?:ended (?:before|without)|disconnected before completion)\b/i), then ran the full string set:

Input	Before	After
stream error: stream disconnected before completion: stream closed before response.completed	PI_AI_ERROR	TRANSPORT ✅
Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	SERVER ✅
Codex error: Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	SERVER ✅
invalid_request_error: bad payload	INVALID_REQUEST	INVALID_REQUEST ✅
401 Unauthorized	AUTH	AUTH ✅
429 Too Many Requests	RATE_LIMIT	RATE_LIMIT ✅
503 Service Unavailable	SERVER	SERVER ✅

So: all three messages from your table classify correctly, precedence is preserved, and the permanent/auth/rate-limit controls are untouched. Your test claims line up with what I measure.

2. What still falls through — 4 cases you may want to add

Input	Before	After	Why
Error Code upstream_stream_read_error: Upstream response stream was interrupted	PI_AI_ERROR	PI_AI_ERROR ❌	the actual trigger captured in the original report
Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed	PI_AI_ERROR	PI_AI_ERROR ❌	same relay family
overloaded (bare word)	PI_AI_ERROR	PI_AI_ERROR ❌	your SERVER pattern requires the full phrase; pi-ai's own transient list contains bare "overloaded" (@earendil-works/pi-ai/dist/utils/retry.js:22)
WebSocket stream closed before response.completed	PI_AI_ERROR	PI_AI_ERROR ❌	\bsocket\b cannot match inside WebSocket (no word boundary between b and S), and the only alternative on that line is the exact phrase WebSocket closed unexpectedly

Suggested narrow additions (same shape as yours):

• /upstream_stream_(read_error|http2_error|truncated)/i → TRANSPORT (these are the relay's stable codes; upstream_stream_truncated already lands on TRANSPORT by coincidence of wording, the other two do not)
• /websocket/i → TRANSPORT — this is the same root cause as Codex WebSocket 1012 被误分类为 PI_AI_ERROR，导致自动重试未触发、长程任务中断 #8722 (Codex WebSocket closed 1012 falling through to the catch-all), so one pattern closes both reports
• /\boverloaded\b/i → SERVER

3. Where the provider code is lost (in case it affects the patch's scope)

The throwing site is not in DSH's adapter — it is in the vendored third-party library: @earendil-works/pi-ai/dist/api/openai-responses-shared.js:640-641 interpolates event.code into a plain Error message. DSH then receives only a string: @deepseek-ai/dsh-llm-pi-ai/lib/index.js:1445-1452 (const text = message.errorMessage ?? "pi-ai stream error"), and pi-ai declares errorMessage?: string (dist/types.d.ts:367) with no structured code field.

For the frame itself, the SDK's own type gives the field set — openai/resources/responses/responses.d.ts:1976-1997: { code, message, param, sequence_number, type: 'error' }. Only type/code/message are proven by the captured message text; param/sequence_number are declared-not-observed (no session log stores raw SSE bytes).

Where the retry decision actually happens: @deepseek-ai/dsh-llm-retry/lib/index.js:160 (if (!policy.retryableCodes.includes(failure.code)) return next();) against DEFAULT_RETRYABLE_CODES at @deepseek-ai/dsh-llm/lib/index.js:251-257 = {EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT}.

4. Your severity point is corroborated in the same session

Same-session A/B from the captured journals: a TRANSPORT turn (DeepSeek Messages transport failed) retried 5× with policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1], while the PI_AI_ERROR turn has zero llm/retry / llm/retry-started frames. The retry executor works; the classification is what fails. And the goal impact you described checks out in code: agent/error (@deepseek-ai/dsh-agent-loop/lib/index.js:880) → disarm(stateFor(agent)) (dsh-goal-round-driver/lib/index.js:201-202) → setActivation(session, "disarmed") (dsh-goal/lib/index.js:624).

5. Version

Your base is the right one to patch: @deepseek-ai/dsh-llm-pi-ai/lib/index.js is byte-identical between 0.2.0-rc.2 and 0.2.1-alpha.1 (SHA-256 d46dbc30aeb3414190000e6f8aeaaf994246b5e5c651de07639f4a7e92de37ef), and DEFAULT_RETRYABLE_CODES is unchanged, so nothing in this area has moved since your base.

6. Agreed on scope

Keeping unknown failures on PI_AI_ERROR and leaving it out of the default retry policy is the right call — the fix should narrow the classification, not widen the retry set. Adding the four patterns above is enough to cover both this report and #8722 without retrying anything unknown.

---

回复：我用原报告里的 relay code 实测了你的 fork patch —— 你列的 3 条已修好，另有 4 条相邻情形仍落兜底

先谢过补丁，也理解你们那边上游不接受外部 PR、所以以 fork 形式给出。我把你的两处生产代码替换应用到了本机已安装的分类器上重跑矩阵，所以下面是独立复测，而不是读 diff 的结论。

1. 你的补丁修好了什么（确认，且无回归）

我从已安装的 @deepseek-ai/dsh-llm-pi-ai/lib/index.js:1380-1391 取下 classifyPiAiError 原文，只应用你 stream.ts 的那两处改动（/\b5\d\d\b|\bour servers are currently overloaded\b/i 与 /stream (?:ended (?:before|without)|disconnected before completion)\b/i），然后跑全套字符串：

输入	打补丁前	打补丁后
stream error: stream disconnected before completion: stream closed before response.completed	PI_AI_ERROR	TRANSPORT ✅
Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	SERVER ✅
Codex error: Our servers are currently overloaded. Please try again later.	PI_AI_ERROR	SERVER ✅
invalid_request_error: bad payload / 401 Unauthorized / 429 Too Many Requests / 503 Service Unavailable	各自正确	全部未变 ✅

即：你表里那三条都归对了，优先级未被破坏，认证/配额/限流/非法请求这些既有分支没有副作用。

2. 仍会落兜底的 4 条（建议一并补）

输入	打补丁前	打补丁后	原因
Error Code upstream_stream_read_error: Upstream response stream was interrupted	PI_AI_ERROR	PI_AI_ERROR ❌	这正是原报告捕获到的真实触发
Error Code upstream_http2_stream_error: Upstream HTTP/2 stream failed	PI_AI_ERROR	PI_AI_ERROR ❌	同一 relay 家族
overloaded（裸词）	PI_AI_ERROR	PI_AI_ERROR ❌	你的 SERVER 分支要求完整短语；而 pi-ai 自己的瞬态列表里就有裸词 "overloaded"（@earendil-works/pi-ai/dist/utils/retry.js:22）
WebSocket stream closed before response.completed	PI_AI_ERROR	PI_AI_ERROR ❌	\bsocket\b 匹配不到 WebSocket 内部（b 与 S 之间没有词边界），该行唯一的显式备选是精确串 WebSocket closed unexpectedly

建议补的三条窄模式（与你的写法同形）：

• /upstream_stream_(read_error|http2_error|truncated)/i → TRANSPORT（upstream_stream_truncated 目前只是因为措辞巧合命中 stream ended before，另两个不命中）
• /websocket/i → TRANSPORT —— 这与 Codex WebSocket 1012 被误分类为 PI_AI_ERROR，导致自动重试未触发、长程任务中断 #8722（Codex WebSocket closed 1012 落兜底）是同一个根因，一条模式可同时关掉两条报告
• /\boverloaded\b/i → SERVER

3. provider code 丢在哪一层（关系到补丁的边界）

抛错点不在 DSH 的 adapter，而在被 vendored 的第三方库：@earendil-works/pi-ai/dist/api/openai-responses-shared.js:640-641 把 event.code 插进一条普通 Error 的 message。DSH 侧只拿到字符串：@deepseek-ai/dsh-llm-pi-ai/lib/index.js:1445-1452（const text = message.errorMessage ?? "pi-ai stream error"），而 pi-ai 声明的是 errorMessage?: string（dist/types.d.ts:367），没有结构化 code 字段。

帧本身，SDK 的类型声明给出字段集：openai/resources/responses/responses.d.ts:1976-1997 → { code, message, param, sequence_number, type: 'error' }；其中只有 type/code/message 有实测证据，param/sequence_number 是"声明有、样本无"（DSH 不保存 SSE wire 原文）。

重试的落点：@deepseek-ai/dsh-llm-retry/lib/index.js:160（if (!policy.retryableCodes.includes(failure.code)) return next();），集合在 @deepseek-ai/dsh-llm/lib/index.js:251-257 = {EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT}。

4. 你说的严重度，在同会话里有对照

同一会话：TRANSPORT（DeepSeek Messages transport failed）重试 5 次，其 llm/retry 的 policyKey = ["normal",5,["EMPTY_RESPONSE","RATE_LIMIT","SERVER","TIMEOUT","TRANSPORT"],500,10000,0.1]；而 PI_AI_ERROR 那一轮 llm/retry / llm/retry-started 0 次。⇒ 不是重试器坏了，是分类错了。goal 影响在代码上也成立：agent/error（dsh-agent-loop/lib/index.js:880）→ disarm(stateFor(agent))（dsh-goal-round-driver/lib/index.js:201-202）→ setActivation(session, "disarmed")（dsh-goal/lib/index.js:624）。

5. 版本

你的基线选得对：@deepseek-ai/dsh-llm-pi-ai/lib/index.js 在 0.2.0-rc.2 与 0.2.1-alpha.1 上逐字节相同（SHA-256 d46dbc30aeb3414190000e6f8aeaaf994246b5e5c651de07639f4a7e92de37ef），DEFAULT_RETRYABLE_CODES 也未变，所以这块自你的 base 起没有移动。

6. 范围我同意

把未知错误留在 PI_AI_ERROR、并且不把它放进默认可重试集合，是对的做法——应该"窄化分类"，而不是"放宽重试集合"。上面四条模式足以同时覆盖本报告与 #8722，且不会让任何未知错误被重试。