dsh-client-connection：history 等大载荷 RPC 受全局 30s 超时限制，Web 端报「历史加载失败：signal timed out (internal)」—— timeoutPolicy 钩子已存在但无人接线

[Chengfengzhishi]

环境：@deepseek-ai/dsh 0.1.1-rc.2（依赖 @deepseek-ai/dsh-client-connection 0.1.1-rc.2）· Windows 11 · Web 面板。

现象：Web 端加载较长会话的历史时报「历史加载失败：signal timed out (internal)」。错误来自 AbortSignal.timeout() 到期被掐断。

复现条件：会话历史较大（长会话、记录数百 KB 级）且宿主正忙（前端同时在生成/压缩）时稳定出现；小会话或空闲宿主不复现。

根因（lib/client.js，0.1.1-rc.2 行号实测）：

@6187  async postJson(path, body, signal, timeoutPolicy = "default") {
@6188    const requestSignal = timeoutPolicy === "default" ? … AbortSignal.timeout(this.timeoutMs) … : signal
@6203  async callUnary(method, payload, signal, timeoutPolicy = "default") {
@6211    const response = await this.postJson(`/api/${method}`, message, signal, timeoutPolicy);

timeoutPolicy 钩子已存在且已贯通到 HTTP 层，但没有任何调用方传非 "default" 策略；this.timeoutMs 默认 DEFAULT_TIMEOUT_MS = 3e4（30s，@6124，仅作构造默认值，唯一构造点不透传 timeoutMs）。history 这类大载荷 RPC 因此与普通 RPC 共用同一 30s 上限，忙宿主下跑不满即被掐断。另注意：@6188 的非 "default" 分支不构造任何库侧超时，请求信号直接采用调用方传入的 signal —— 若调用方只传一个策略字符串而 signal 缺省（undefined），该请求将完全没有超时。

建议修法：让 history（及同类大载荷 RPC）的调用方传非 "default" 的 timeoutPolicy，并自带更长的 AbortSignal（如 AbortSignal.timeout(3e5)）；或由库新增具名策略（如 "long" ≈ 300s）并在该分支构造对应超时（调用方无需自造 signal）；或按载荷大小自适应放宽超时。钩子已在，改动面很小。

临时缓解（本机已用）：把 lib/client.js 里 DEFAULT_TIMEOUT_MS 由 3e4 改 3e5（单字节改动）。注意它在 node_modules 里，升级/重装会静默还原；且构造点不透传 timeoutMs，用户侧没有任何配置入口 —— 若能提供配置项或让调用方自带策略更佳。

影响面：若只全局调大默认值，「真卡死的宿主」要多等 5 分钟才报错；按策略/按载荷放宽不影响快速失败语义。

[PerryLink]

这份报告与 #7143 是同一份（正文逐字一致），根因成立；逐行链路我写在 #7143 了，这里只放结论和当前状态。

• 30s 定义在当时的 packages/host/apiproxy/src/fetch/client.ts:228（tag dsh-v0.1.1-rc.2，DEFAULT_TIMEOUT_MS = 30_000），由 postJson 的默认策略在 :313-316 施加；session.history 走的就是默认策略（:416），而 UI 打开会话时连 signal 都没传（packages/client/runtime/src/client/sessions/session.ts:623、:780-783），所以这是那个请求唯一的截止。界面上的 (internal) 来自 transportError（packages/host/apiproxy/src/api/rpc.ts:122）。
• 它不是全局常量，而是每个客户端实例的构造参数（:251）——但生产构造点 new WebApiClient() 不传（packages/client/connection/src/client/index.ts:114，同 tag），壳侧扩展点 createApiClient() 也不收参数（同文件 :64），用户侧没有任何入口。这是你这条报告里最有价值的一点。
• 覆盖范围：所有一元调用与 respond（client.ts:341、:510）；两条下行 SSE／WebSocket 流不走这个超时（:354-359、packages/client/connection/src/client/web-api-client.ts:23-31）。唯一传非默认策略的是 host.pickDirectory（:438-439）。
• 现状：4f00a8b82a（refactor(api): remove ApiProxy package）删掉了整个 apiproxy，从 dsh-v0.1.2-alpha.1 起所有 tag 都不含这段代码；HEAD ddefc45 的浏览器 RPC 只透传调用方给的 signal（packages/client/connection/src/client/rpc.ts:43-51），packages/client、packages/api 里已无 AbortSignal.timeout。所以升级本身就能脱离这道 30s，那个改 node_modules 的临时补丁可以撤了。
• 另外一点：30s 到期只让客户端放弃等待，宿主侧那页仍会读完——session.history 的路由忽略载体 signal（packages/host/apiproxy/src/fetch/handler.ts:94），所以它不会因为超时而停下。

未验证：升级后忙宿主下的实际延迟，以及宿主侧当时为什么慢。