[Bug] pi-ai localized timeout text is classified as PI_AI_ERROR and skips retry

[xiangyuliu]

Summary

dsh-llm-pi-ai recognizes English timeout / timed out text, but a gateway
that reports the localized Chinese message upstream_error: 请求超时 falls
through to PI_AI_ERROR. Since the generic code is not retryable by default,
a real transient timeout terminates the turn immediately.

Environment

• macOS 26.6.1 (25G76)
• Node.js 24.19.0
• @deepseek-ai/dsh@0.1.5-rc.1
• @deepseek-ai/dsh-llm-pi-ai@0.1.5-rc.1
• custom GPT-family model through llm-pi-ai / openai-responses

Minimal synthetic reproduction

Pass this provider error text through the stopReason === 'error' path:

upstream_error: 请求超时

Current classification in packages/llm/llm-pi-ai/src/stream.ts:

if (/\btime(?:d)?\s*out\b|timeout/i.test(message)) return 'TIMEOUT'

Observed result: PI_AI_ERROR and no llm/retry event.

Expected result: TIMEOUT, allowing the existing provider retry policy to
decide whether and how often to retry.

Suggested narrow change

if (/\btime(?:d)?\s*out\b|timeout|请求超时/i.test(message)) return 'TIMEOUT'

Suggested regression cases:

expect(classify('upstream_error: 请求超时')).toBe('TIMEOUT')
expect(classify('upstream_error: 请求失败')).toBe('PI_AI_ERROR')

The negative case is important: this should not turn arbitrary localized
upstream errors into retryable timeouts. No change to the default retry count is
requested; deployments can still choose a smaller maxRetries when one gateway
timeout is already expensive.

Longer term, preserving a structured error/status/cause from pi-ai would be
preferable to expanding text heuristics, but the current adapter explicitly has
only flattened error.message text available.

[PerryLink]

复核确认：packages/llm/llm-pi-ai/src/stream.ts:51 的超时分类正则 /\btime(?:d)?\s*out\b|timeout/i 只匹配英文 timeout/timed out；网关返回的中文 upstream_error: 请求超时 不命中 → 落入通用 PI_AI_ERROR，而默认重试策略不重试该码 → 瞬时超时无法自愈。与你的结论一致。

修复方向极小：正则扩一条 超时 分支（或对 upstream_error 前缀 + 超时关键字组合判 TIMEOUT），保留英文分支即可；这是可测的一行级改动。

同族两条：

• [Bug] pi-ai/OpenAI Responses: data-only keep-alives reach JSON.parse #6593（data-only keep-alive 进 JSON.parse）：解析发生在 vendored SDK（@earendil-works/pi-ai）内部，harness 侧适配器是外层（adapter.ts:354-355 的 idle watchdog、:415 的报错）。建议在 adapter 边界加一层窄兼容过滤，丢弃纯 keep-alive/注释帧再喂给 SDK。
• [Bug] OpenAI Responses final item completes but missing response.completed hangs until idle timeout #6594（缺 response.completed 挂到 idle timeout）：机制与 watchdog 一致——内容已完整但流未闭合时只能等 300s 空闲超时。建议在 SDK 流"内容完整但未 completed"时提前结算，或在 adapter 层对完整内容做兜底。
  诚实标注：[Bug] pi-ai/OpenAI Responses: data-only keep-alives reach JSON.parse #6593/[Bug] OpenAI Responses final item completes but missing response.completed hangs until idle timeout #6594 我未逐行映射 SDK 内部实现，两条的修复点都在 SDK 边界，需要 SDK 侧确认。
  三条都是第三方网关兼容性问题，修复成本都不高；需要的话我可以把三条合并成一个带复现的 DSH master (0.1.6-alpha.2 / ddefc45fbc) 仍未修复的问题清单（社区核实版） #6520 清单条目。

---

# 结尾计数

- #6520：新评论 1（crper，元评论 → 无清单改动；可选回复草稿 1 份）；正文需更新 2 处计数 + 第 7 条相关讨论 + 建议新增第 27 条（fs-ext，已核实，附精确追加文本）+ 候选第 28 条（#6575，待触发条件补全）。
- 新讨论扫描：窗口内 67 条（#6545–#6612）。WORTH_ANSWERING 31 / ALREADY_ANSWERED 4 / OUR_OWN 0 / SKIP 32。完整答案草稿 8 份（#6589、#6584、#6575、#6603、#6599、#6553、#6571、#6595），全部标注诚实标记，未发帖。
- GitHub 全程只读；本会话仅写入 D:\Projects\p3-6520-new.md 及 p3-* 临时 JSON/文本文件。