在0.1.68版本接入dsh时遇到的问题 #437

Activity

1. ranxianglei commented on Sep 1, 2026

   

   ranxianglei

   on Sep 1, 2026

   Owner

   More actions

   ework 接单
2. ranxianglei commented on Sep 1, 2026

   

   ranxianglei

   on Sep 1, 2026

   Owner

   More actions

   🤖 ework agent · qwen3.8-27b

   已定位并修复。

   根因：fetchWithTimeout（src/fetch-util.ts）用的是一个总时长定时器（UPSTREAM_TIMEOUT_MS = 10 分钟），只有当响应体完全读完后才会清除。所以一个健康的、正常跑了超过 10 分钟的流式输出（比如 DeepSeek 的长生成），会在第 10 分钟被强制 abort —— for await 循环抛错，emitStreamError 写入 ❌ [ACP] stream error + finish 事件，客户端就看到对话被截断了。

   修复：把超时改成**空闲（idle）**语义 —— 每收到一个响应体 chunk 就重置一次定时器。效果：

   • 健康的长流（持续有 chunk）不会再在流中途被掐断；
   • 真正卡死的流（timeoutMs 内没有任何 chunk）依旧会被 abort；
   • 首字节（time-to-first-byte）的兜底不变；
   • clearTimer / 客户端断开（externalSignal）语义保持不变，调用方看到的 Response 形状（status/headers/body）一致。

   改动集中在 fetchWithTimeout，因此覆盖所有上游路径（主 forward()、preflight、compress-loop 重放请求、registry）。

   测试：

   • 新增 tests/fix-437-idle-timeout.test.ts：健康长流完整跑完（已验证在旧的"总时长"实现下该用例会失败）；卡死流仍会被 abort；包装后的 body 保留 status + headers。
   • npm run typecheck 通过；npm test 899/899 通过；npm run build 通过。

   PR：#439

   （E2E 需要真实的 codex 客户端 + 本地 Responses 上游，本环境不具备；此改动是 fetchWithTimeout 里孤立的超时语义变更，未触碰任何消息重建/改写逻辑，已由完整单测覆盖。合并前如有上游环境，建议跑一下 E2E 核心。）
3. ranxianglei

   added a commit that references this issue on Sep 2, 2026

   Merge pull request #439 from ranxianglei/2026-09-02_fix-437-idle-timeout

   ...

   ebdfa78
4. ranxianglei commented on Sep 2, 2026

   

   ranxianglei

   on Sep 2, 2026

   Owner

   More actions

   已经合并 等待发新版本
5. ranxianglei

   closed this as completedon Sep 2, 2026
6. antclt

   added 2 commits that reference this issue on Sep 2, 2026

   fix(ranxianglei#437): make upstream timeout idle-based so long health…

   ...

   65cd535

   refactor: drop the dead SSE rewriters that kept causing mis-triage

   ...

   6e9092b