Codex WebSocket 1012 被误分类为 PI_AI_ERROR，导致自动重试未触发、长程任务中断

[Flipped929]

反馈一个 Codex 通道的故障恢复问题：DSH 桌面版使用 openai-codex（ChatGPT Pro OAuth，gpt-6.1-sol）执行长程任务时，遇到“WebSocket closed 1012 / PI_AI_ERROR”后本轮直接失败，需要人工继续。已核对当前安装包中的 @deepseek-ai/dsh-llm-pi-ai 0.2.0-rc.2，并通过测试复现：classifyPiAiError("WebSocket closed 1012") 返回 PI_AI_ERROR，而非 TRANSPORT；原生 dsh-llm-retry 的默认可重试名单不包含 PI_AI_ERROR，因此自动恢复未被触发。另据 pi-ai 实现，若断开发生在流式输出开始后，本轮会抛错，同时标记该会话后续请求使用 SSE，这使正确的错误分类尤为重要。建议将明确的临时 WebSocket 关闭码（至少1012）归为 TRANSPORT，接入已有的有限次数、可取消的退避重试；不要将所有 PI_AI_ERROR 泛化为可重试，也不要重放已完成的工具操作。我们已用独立本地兼容插件验证该修法，31项隔离测试通过，覆盖重试上限、取消、错误白名单和非重试错误保留；真实服务断线后的端到端恢复尚待观察。断线来源是否为 OpenAI 后端或中间网关尚未确定，但 DSH 端的错误分类遗漏已复现。

[PerryLink]

我能告诉你为什么这一条会落进 PI_AI_ERROR——分类器里已经有 WebSocket 分支，只是它匹配的是另一种措辞

1. 确切的失配点

packages/llm/llm-pi-ai/src/stream.ts 的 classifyPiAiError 里，TRANSPORT 分支是：

|| /\b(?:other side closed|HTTP2 request did not get a response|WebSocket closed unexpectedly)\b/i.test(message)   // :60

⇒ 它匹配的是 WebSocket closed unexpectedly，而你的报错是 WebSocket closed 1012——没有 unexpectedly 这个词，正则不命中，于是落到函数末尾的兜底 return 'PI_AI_ERROR'。你观察到的"被误分类为 PI_AI_ERROR"成立，而且原因就是这一处措辞差异。

这同时说明一件对你有利的事：TRANSPORT 分支的存在本身就是"WebSocket 断开应归为传输类"的既有设计意图——你要求的不是新增一类，而是让既有的那条意图覆盖真实措辞。建议在报告里这样写，它比"请把 1012 归为 TRANSPORT"更容易被接受。

2. 你的两条边界条件我完全同意（建议保留）

• 不要把 PI_AI_ERROR 整体加入可重试：它是兜底码，泛化会把"不可重试的错误"变成重试——方向相反的错更难查；
• 不要重放已完成的工具操作：这是重试语义的底线。

⇒ 建议把诉求精确成：在 :60 那条模式里补上显式的关闭码（至少 1012、以及其它明确的临时关闭码），并沿用既有的有限次数 / 可取消退避重试，不改白名单、不改重放语义。

3. 一处需要留意（对你有用）

你说"若断开发生在流式输出开始后，本轮会抛错，同时标记该会话后续请求使用 SSE"。⇒ 那么分类正确的收益不止"这一次会重试"，还包括避免把会话推进到后续形态。建议把这一点写进影响面——它解释了为什么"分类错了"的代价大于一次失败。

4. 版本口径

你核的是安装包里的 @deepseek-ai/dsh-llm-pi-ai 0.2.0-rc.2；当前最新是 0.2.1-alpha.1。请复核 :60 那条模式在新版是否已扩（0.1.7-rc.2 → 0.2.1-alpha.1 有 714 个提交，packages/llm 有 70 个）：

npm i -g @deepseek-ai/dsh          # 0.2.0-rc.2（现在的 latest）
npm i -g @deepseek-ai/dsh@alpha    # 0.2.1-alpha.1

若新版仍只匹配 unexpectedly，那这条就是当前存活的缺陷，按上面的最小改法提即可。

一条边界

我确认的是该正则在当前源码中的措辞与你报错文本不匹配（这足以解释误分类）。"1012 属于临时性关闭码"这一判断以你的领域核对为准——我没有核 OpenAI/网关侧对 1012 的定义；你在正文里也写了"来源尚待确定"，这个保留是诚实的，建议保持。