[Bug] 大型冷态子代理历史因 30 秒 unary 时限无法加载

[P0lar1ght]

在 dsh web 0.1.0-rc.8 中，大型 continuable 子代理的冷态历史无法通过 Web UI 加载，页面稳定显示：

历史加载失败：signal timed out（internal）

与 #3413 的区别

#3413 讨论的是远程链路下 3 秒 streamOpenTimeoutMs readiness guard；本次发生在本机 127.0.0.1，失败请求是 POST /api/subagent.history，时间点与通用 unary 的 30 秒截止时间一致。普通父会话历史和 WebSocket 连接均正常。

复现步骤

1. 使用 dsh 0.1.0-rc.8 启动 Web profile。
2. 打开一个包含大型 continuable 子代理历史的父会话。
3. 展开子代理目录，打开该子代理。
4. 等待约 30 秒。

实际结果

• 页面显示 历史加载失败：signal timed out（internal）。
• UI 请求使用 maxMessages: 50。
• 同一父会话的普通历史能够正常加载。
• 相同 subagent.history payload 通过直接 HTTP 调用并允许更长 client timeout 后返回 HTTP 200，因此日志本身未损坏。
• 本次尾页包含 24,878 条原始事件，响应约 5,242,159 字节；对应的 session.jsonl.zstd 约 995 KiB。

原因分析

当前源码在 packages/host/apiproxy/src/fetch/client.ts 中为普通 unary 调用设置 DEFAULT_TIMEOUT_MS = 30_000，postJson() 使用 AbortSignal.timeout(this.timeoutMs)。目前 session.history 和 subagent.history 都走默认 callUnary() 路径，没有使用 caller-signal-only 策略。

历史分页的 maxMessages 只限制 append-origin message 数量，不限制其中的 chunk、tool、step 事件数量或最终 JSON 字节数。一次合法的 message-aligned 尾页因此可能包含数万条事件；冷态子代理还需要完成 catalog 校验、持久化 inspection、projection restore、分页和序列化，整体耗时可能超过 30 秒。

Fetch 超时异常随后被 packages/host/apiproxy/src/api/rpc.ts 的 transportError() 统一转换为 internal，于是 UI 暴露了底层 signal timed out，容易被误判为日志损坏或 Host 内部错误。

session.history 使用相同的默认 timeout policy，因此大型普通冷会话理论上也可能受影响；本次稳定复现发生在 subagent.history。

预期结果

• 合法的大型历史可以完成加载，不应仅因超过通用 transport-health 时限而失败。
• 如果历史读取必须有上限，应提供与历史工作量相关的明确诊断或受控分页，而不是显示底层 signal timed out（internal）。
• 调用方或连接取消仍应能够终止读取。

环境

• DeepSeek Harness：0.1.0-rc.8
• Commit：141eb6fef83422698aef7a981029e843e8161534
• Node.js：v25.2.1
• macOS：26.6.1
• Architecture：arm64
• Carrier：Web，http://127.0.0.1:3080

建议的回归覆盖

• 历史 RPC 合法执行时间超过默认 unary deadline 时仍可完成，或通过历史专用的明确策略结束。
• 大型冷态 subagent.history 可从 Web UI 加载。
• 同样的数据量语义覆盖 session.history。
• 普通 unary 请求仍保留 transport-health deadline。
• 历史读取仍响应 caller/connection cancellation。
• UI 不再把预期的历史读取耗时显示为原始 signal timed out（internal）。

[argszero]

在 rc.8（141eb6fef8）逐行验证，你的分析全部成立——并且有一个重要的好消息：你要的 caller-signal-only 策略已经存在于代码里，修复实际是两行接入，而不是新设计。

验证你的全部源码引用（属实）

• fetch/client.ts:228 DEFAULT_TIMEOUT_MS = 30_000，postJson :315-316 用 AbortSignal.timeout(this.timeoutMs) 与外部 signal 合并。
• session.history（client.ts:416）与 subagent.history（client.ts:429）都调用 callUnary(method, payload, signal)——第 4 参 timeoutPolicy 缺省为 'default' → 30 秒硬时限强制生效。
• rpc.ts:119-127 transportError() 把 AbortError 的 message 原样包成 code: 'internal' → UI 显示底层 signal timed out（internal）。

增量 1（核心）：caller-signal-only 已是现有设计，修复 = 两行

• client.ts:231 type UnaryTimeoutPolicy = 'default' | 'caller-signal-only'——策略类型已定义。
• 先例：client.ts:439 host.pickDirectory 已用 'caller-signal-only'，注释 :250 说明语义："timeoutMs - timeout for bounded unary calls; user-paced calls and streams do not use it"。
• 历史加载正是 user-paced 操作（用户打开子代理页等渲染），与 pickDirectory（等用户选目录）同语义。修复 = 给 client.ts:416 与 :429 两处加第 4 参 'caller-signal-only'——比"引入新策略"小一个量级。

增量 2：server 侧已尊重 signal → caller-signal-only 不会积压 handler

• fetch/handler.ts:104 的 subagent.history 路由：invoke 已把 signal 透传给 subagents 域的 history 实现——server 侧读取全程可被取消。
• 所以切到 caller-signal-only 后：浏览器 tab 关闭 / 用户离开页面 / 连接取消 → client signal abort → server handler 收到取消 → 长读及时中断，不会占住 worker。你的预期 3（"调用方或连接取消仍应能够终止读取"）在现有架构里已天然满足，这正是该策略能安全应用的依据。

增量 3：家族连接（为什么 30 秒时限在此处尤其不合理）

• 冷态大历史读取耗时是真实工作量而非 health 问题——与 [Bug] Cold history loading fully materializes large/corrupt logs and can stall the entire Web server #1550/Title: [Bug] Single corrupted session.jsonl.zstd causes full DoS — no graceful degradation #2998 同源：全帧解码 + 逐事件深冻结 + projection restore，级联成本随事件数线性放大。用 transport-health 时限（30 秒，为"请求-响应往返健康"设计）裁工作量型读取，语义错配。
• 与 cordis_inspect_query client-platform queries hang forever when no page responds, freezing the agent #1607/userQuestions: single global provider without timeout hangs non-web channels (WeChat/Telegram gateways) forever #2544（无界等待家族）相反——那边的问题是无超时挂起，这里是有硬时限但无进展反馈；两个极端之间的正确形态 = 长任务跟随调用者生命周期（caller-signal-only）+ UI 显式加载态，而不是一个全局秒数。
• 补充：maxMessages: 50 只限制 append-origin message 数、不限制 chunk/tool/step 事件数与字节数（你的 24,878 事件 / 5.2MB 响应证明了这一点）——这是分页粒度独立于超时策略的第二个问题，值得单独跟踪（按事件数或字节预算分页）。

修复形态汇总

1. 主修复：client.ts:416 session.history + :429 subagent.history 加 'caller-signal-only'（两行，先例 :439）。
2. 诊断改善：transportError 对 TimeoutError/AbortError 给可读分类（如 'TIMEOUT'）而非 internal，让 UI 不再把长读超时伪装成内部错误——与 前端报错无法区分"后端已死"与"网络瞬断"——建议 /health 心跳 + 崩溃引导 #3585 的"前端报错分级"同方向。
3. 回归覆盖：一个耗时超过 30 秒的 fixture 历史（或 mock 延迟）验证 caller-signal-only 下完成 + 取消仍中断。

需要的话我可以把第 1 项的 diff 草案贴出来——两行接入 + 一个回归测试形态。