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]

你的根因判断在 0.1.1-rc.2 上成立，链路还能再补完整一点：这 30s 来自当时的 packages/host/apiproxy/src/fetch/client.ts（tag dsh-v0.1.1-rc.2），不是 dsh-client-connection 的源码——你在 lib/client.js 里读到的是它的打包产物。

链路（行号均为 tag dsh-v0.1.1-rc.2）：

• 常量与策略：packages/host/apiproxy/src/fetch/client.ts:228（DEFAULT_TIMEOUT_MS = 30_000）、:231（type UnaryTimeoutPolicy = 'default' | 'caller-signal-only'）、:251（构造参数的默认值）。
• 库侧唯一施加点：:313-316，默认策略下 requestSignal = AbortSignal.timeout(this.timeoutMs)，调用方另给 signal 时是 AbortSignal.any([AbortSignal.timeout(this.timeoutMs), signal])。
• session.history 没有传策略：:416（history: (payload, signal) => this.callUnary('session.history', payload, signal)），callUnary 的默认策略在 :333-337；子代理历史同理（:429）。
• UI 打开会话时连 signal 都没传：packages/client/runtime/src/client/sessions/session.ts:623 调 :780-783 的 this.api.sessions.history({ sessionId, ...payload })，所以 AbortSignal.timeout(30s) 是那个请求唯一的截止。
• 报错文案也对得上：session.ts:639-644 把抛出的异常折进 transportError，后者在 packages/host/apiproxy/src/api/rpc.ts:119-124 固定给出 code: 'internal'，再由 packages/client/ui-conversation/src/client/locales.ts:92 渲染成「历史加载失败：{message}（{code}）」。

三处修正／补充：

1. 「没有任何调用方传非 default 策略」不准确：host.pickDirectory 传了 'caller-signal-only'（client.ts:438-439），因为原生目录对话框是用户节奏的。
2. 传 signal 也不会放宽它：:316 是 AbortSignal.any，调用方的 signal 只会更早掐断，30s 上限原样保留。
3. 30s 到期不会中止宿主侧的工作：session.history 那条路由忽略载体 signal（packages/host/apiproxy/src/fetch/handler.ts:94；对照同一表里 :92、:103 会转发 signal 的几条），而 handleUnary 拿到的是 req.signal（:317）。客户端只是不再等，宿主仍把这一页读完。

用户侧确实没有入口：timeoutMs 只能由构造参数给，而浏览器载体的生产构造点是 new WebApiClient()（packages/client/connection/src/client/index.ts:114，同 tag），壳侧扩展点 createApiClient(): IApiClient 也不收参数（同文件 :64）。所以改 node_modules 在当时是唯一手段，而它会随重装还原——这点你说得对。

现状：这个 30s 已经不在代码里了。4f00a8b82a（refactor(api): remove ApiProxy package）删掉了整个 packages/host/apiproxy，该提交被 dsh-v0.1.2-alpha.1 及之后每个 tag 包含；HEAD ddefc45 的浏览器 RPC 只在调用方给了 signal 时才带 signal（packages/client/connection/src/client/rpc.ts:43-51），并且 packages/client、packages/api 两个目录里已经没有 AbortSignal.timeout（我在这两个目录搜过）。history 现在走 Gateway Remote 流（packages/api/session-controller/src/client/transport.ts:172-183、:223-235）。要脱离这道上限，升到 0.1.2-alpha.1 之后即可，不必再打补丁。

未验证：lib/client.js 里的打包行号（@6124/@6187/@6203/@6211）我没读，我只核了 tag 里的源码行号；在 tag dsh-v0.1.1-rc.2 的 packages/client、apps、packages/host 里搜 AbortSignal.timeout，非测试命中只有 fetch/client.ts:315-316，所以「signal timed out」只可能来自这条路径——这是推断，我没有你那台机器的日志；「宿主忙时 history 页为什么慢」我没有证据；升级后忙宿主下是否仍让你觉得慢，我也没验证，只是客户端那道 30s 硬截止不再存在。

（同一份报告还有 #7144。）