[Bug follow-up][0.2.1-alpha.2] upstream_http2_stream_error still becomes non-retryable PI_AI_ERROR

[jghwwnq]

Summary

This is a focused follow-up to #8844. The exact upstream_http2_stream_error case is still reproducible on the current master commit, d743267388641bc76f17c45ce8b4c231aed1d32c (0.2.1-alpha.2).

An OpenAI Responses failure with:

{
  "type": "response.failed",
  "response": {
    "error": {
      "code": "upstream_http2_stream_error",
      "message": "Upstream HTTP/2 stream failed"
    }
  }
}

reaches DSH as:

upstream_http2_stream_error: Upstream HTTP/2 stream failed

but is classified as PI_AI_ERROR. Because the normal retry policy does not include PI_AI_ERROR, the transient stream interruption ends the turn without an automatic retry.

Real Desktop reproduction

Environment:

• DSH Desktop source build 0.2.1-alpha.2-d743267
• macOS x64
• pi-ai openai-responses route
• model gpt-6-astra, reasoning effort max

Observed session facts:

1. Turn 4, step 51 started receiving a reasoning block.
2. About 12 seconds later it ended with failure.code = PI_AI_ERROR and message = Upstream HTTP/2 stream failed.
3. The turn contains zero llm/retry and zero llm/retry-started events.
4. The failed step contains no tool-call block, so this occurrence left no tool execution with an unknown outcome.
5. Continuing the same session succeeded on the same provider and model a few minutes later.
6. The active context was approximately 62K tokens against a 272K-token window, so this was not a context-window failure.

The interruption itself is an upstream or relay transport failure. The DSH defect is the classification and resulting retry bypass.

Current source behavior

packages/llm/llm-pi-ai/src/stream.ts recognizes this older HTTP/2 wording:

HTTP2 request did not get a response

It does not recognize either the stable code or the current message:

upstream_http2_stream_error
Upstream HTTP/2 stream failed

The value therefore falls through to PI_AI_ERROR. The default retry set remains:

EMPTY_RESPONSE, RATE_LIMIT, SERVER, TIMEOUT, TRANSPORT

Minimal fix tested locally

The narrow compatibility fallback is:

 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)
+  || /\bupstream_http2_stream_error\b|\bupstream HTTP\/2 stream failed\b/i.test(message)
   || /\bterminated\b|premature close/i.test(message)) {
   return 'TRANSPORT'
 }

This keeps genuinely unknown failures on PI_AI_ERROR; it does not make the catch-all retryable.

Local regression coverage includes:

• conversion tests for the bare message and the flattened stable-code form;
• a loopback OpenAI Responses response.failed test that asserts the original message is retained and the DSH code is TRANSPORT;
• a keyless recorded-session snapshot proving assistant/attempt(TRANSPORT) -> llm/retry -> llm/retry-started -> assistant/message;
• 143 focused adapter tests, typecheck, lint, 21 documentation checks, and all 43 doc-sync gates passing.

Requested action

Please land the narrow TRANSPORT mapping for upstream_http2_stream_error / Upstream HTTP/2 stream failed on top of current master. Preserving the provider code structurally should remain the longer-term fix when pi-ai exposes it separately from errorMessage, but the narrow mapping restores the existing bounded retry behavior now.

This follow-up is intentionally narrower than #8844: it records a current-release/current-master reproduction of the exact HTTP/2 variant and a tested minimal patch.

[PerryLink]

这条完全成立，而且我把"码从哪来"也找到了 —— 它就在上游字符串里。另外你结尾那句"等 pi-ai 把 code 独立暴露"不必等。

1. 分类链逐字确认

packages/llm/llm-pi-ai/src/stream.ts:42 → function classifyPiAiError(message: string): string { —— 纯文本匹配，没有结构信息。

白名单在 :59-66，确实只覆盖旧措辞：

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)) {
  return 'TRANSPORT'
}

:67 → return 'PI_AI_ERROR'（兜底）。:125 → return { kind: 'error', failure: { message: text, code: classifyPiAiError(text) } }。

upstream_http2_stream_error: Upstream HTTP/2 stream failed 里没有 network/connection/socket/fetch/ECONN*，也不匹配 HTTP2 request did not get a response ⇒ 落到 PI_AI_ERROR。你的判断准确。

2. 不进重试的精确闸门

• packages/llm/llm/src/retry-policy.ts:14 → const DEFAULT_MAX_RETRIES = 5
• :18-24 → DEFAULT_RETRYABLE_CODES = Object.freeze([EMPTY_RESPONSE_CODE, 'RATE_LIMIT', 'SERVER', 'TIMEOUT', 'TRANSPORT']) —— PI_AI_ERROR 不在其中
• packages/llm/llm-retry/src/index.ts:215 → } else if (!policy.retryableCodes.includes(failure.code)) { return next() } ← 就是这里直接放行

⇒ 与你观察到的"零 retry 事件"完全吻合：连 llm/retry 都不会产生。默认策略确实生效（llm-pi-ai/src/adapter.ts:284、config.ts:500、llm/src/retry-policy.ts:153-159；旁证 llm-pi-ai/README.md:89 的 | retryPolicy | normal, 5 retries |）。

3. ⭐ 码从哪来 —— 它已经在字符串里

我拉了 origin/master lock 钉的 @earendil-works/pi-ai@1.0.2（packages/llm/llm-pi-ai/package.json 声明 ^1.0.2；pnpm-lock.yaml 同版），其 dist/api/openai-responses-shared.js:645-655 的 response.failed 分支：

const msg = error ? `${error.code || "unknown"}: ${error.message || "no message"}` : …
throw new Error(msg)

⇒ 生成的正是 `upstream_http2_stream_error: Upstream HTTP/2 stream failed` —— 与你贴的字符串逐字一致。

⚠️ 顺带一个坑：本机 node_modules 里装的是 pi-ai 0.87.1（本地 HEAD 时代的旧版），拿它验证会得出错误结论。我上面的结论取自 1.0.2。

所以修法不必等上游：

既然字符串形状是 `${code}: ${message}`，DSH 现在就能从 message 开头解析出 code，不需要 pi-ai 把 code 独立暴露。

建议把你这句改掉 —— 它会让维护者以为要等上游，从而降低优先级。

4. 我建议把修法从"逐码枚举"改成"解析码前缀"

你的窄补丁方向正确、也不扩大兜底，可以接受。但既然 server_error（你的另一帖）与 upstream_http2_* 整族是同一个形状，一次覆盖更划算：

• 匹配 pi-ai 的 `${code}: ` 前缀（如 /^(?:[a-z][a-z0-9_]*):\s/i），再对一张已知瞬时码表判定
• 或至少用 /\bupstream_http2_\w+\b/i 覆盖整族，而不是只枚举 upstream_http2_stream_error 一个

关键是保持"白名单"结构：不要因为省事就把 PI_AI_ERROR 整体加进 retryableCodes。这一点你的克制是对的 —— pi-ai 的 pending / deferred 也发 PI_AI_ERROR（stream.ts:111-118），放宽会把永久失败变成无限重试。

分支顺序也要保持在其后（:43-49 的 401/403、quota、429、413、400 优先级）—— 这一点你也说对了。

5. 一个你没提、但能解释"为什么以前没发现"的事实

stream.ts:34-41 有一条 XXX(pi-ai upstream) 注释，说 pi-ai 会把捕获到的错误压成 error.message、丢掉原始 Error 与 cause 链。维护者知道这里只能做文本分类 —— 所以你的补丁形态（在文本层加码）正合它的现状，不需要先解决上游丢 cause 的问题。这一点值得引用，它能让补丁立刻可接受。

6. 版本

你标 0.2.1-alpha.2 / commit d743267388 —— 我独立复核了 git rev-list --count d743267388..origin/master = 0，你标的就是当前 master，未过期。而且我核对了 fetch 时间（晚于你的发帖），确认这不是自称。

7. 一条边界

你本机的 regression 测试数字（143 等）属于你的私有改动，我没有核实 —— 那不影响上面的源码结论，但建议在报告里标为"本机测试"。

8. 与 #9502 的关系

你和 server_error 那帖（#9502）是同一天同一族问题，共享同一条闸门（llm-retry/src/index.ts:215）与同一个上游字符串生成点。建议两帖互相引用，并把"解析 code: 前缀 + 已知瞬时码表"作为一份通用修法提交 —— 一次覆盖 server_error、upstream_http2_stream_error 与 upstream_http2_* 整族，维护者的评审成本会低很多。