Web UI 发送消息偶发报错 "signal timed out (internal)"：unary RPC 固定 30s 超时且不可配置

[Natura-a]

Bug Report：DSH web UI 发送消息偶发超时 signal timed out (internal)

• 仓库：deepseek-ai/deepseek-harness
• 提交地址：https://github.com/deepseek-ai/deepseek-harness/issues/new
• 严重程度：中（可用性问题，偶发、重试可恢复）

环境

• Windows 11 10.0.26200 (x64)
• Node.js v24.19.0
• @deepseek-ai/dsh 0.1.0-rc.6
• web profile 以 Windows 服务方式运行（nssm，LocalSystem，session 0，端口 3080）

现象

• Web UI 发送消息偶尔失败，聊天中插入错误气泡：signal timed out (internal)
• 偶发，重试通常能成功；与 host 负载相关（安装多个插件 / 后台有任务运行时更易触发）

证据

• 客户端连接层 dsh-client-connection/lib/client.js：
  • DEFAULT_TIMEOUT_MS = 3e4（30 秒固定值，非配置项）
  • postJson() 对 unary RPC 无条件附加 AbortSignal.timeout(30s)：

    const requestSignal = timeoutPolicy === "default"
      ? signal === void 0 ? AbortSignal.timeout(this.timeoutMs)
      : AbortSignal.any([AbortSignal.timeout(this.timeoutMs), signal])
      : signal;

    超时即中止，抛出的 DOMException 文案正是 signal timed out (internal)。
  • 聊天发送走 unary RPC（如 session.prompt，返回 receipt），receipt 超过 30s 未返回即失败。
• host 为单进程，同时承载 agent loop + 12 个常开 MCP stdio server + 插件；事件循环繁忙时 unary RPC 容易越过 30s 被误杀。
• 该超时值在 profile 配置中无透出项，无法调整。

期望 vs 实际

• 期望：host 繁忙时应排队/延后处理，而非用固定 30s 误杀用户发送；错误信息应可定位（哪个 RPC、哪个环节、超时时长）。
• 实际：固定 30s 超时 + 含糊文案，用户无法区分是客户端连接问题、host 繁忙还是 provider 慢。

建议

1. 超时值可配置（profile patch / 设置项），默认值可调大（如 60s）。
2. 错误文案带上上下文：RPC 方法名、超时时长、host 状态。
3. 对发送类 RPC 采用更宽松的超时策略（代码中已有 user-paced / stream 免超时策略，可扩展）。

---

AI 标识：本报告由 AI 辅助生成（ZCode · DeepSeek-V4），技术事实、代码行号与版本号经人工核实；提交前建议再自查一遍关键行号与版本号。

[zoahdev]

Root cause confirmed at source level.

packages/host/apiproxy/src/fetch/client.ts:

const DEFAULT_TIMEOUT_MS = 30_000                       // line 228
constructor(protected readonly timeoutMs: number = DEFAULT_TIMEOUT_MS) {}  // line 251
// postJson (line 315-316) applies AbortSignal.timeout(this.timeoutMs) to every unary RPC

The constructor is already parameterized; the gap is that the browser-facing WebFetchClient is instantiated with the hardcoded 30s and nothing exposes a setting/env to raise it. So a heavy session.prompt under host load (multiple plugins / background tasks) can legitimately exceed 30s and the client aborts with signal timed out (internal).

Immediate mitigations

• Reduce concurrent load: fewer heavy plugins or background tasks drops the prompt latency back under 30s.
• If you can run a local reverse proxy in front, it can absorb the slow unary and return when ready (hacky, but unblocks a stuck nssm deployment).

Proper fix

Plumb a configurable timeout into the web client - e.g. honor DSH_RPC_TIMEOUT_MS (or a settings key) when constructing WebFetchClient, keeping 30s as the default so nothing changes for existing setups. This is a small, bounded patch; happy to prepare it as a cherry-pick-ready branch in the same queue as our other upstream fixes if you want.

[zoahdev]

Implemented as a cherry-pick-ready branch - and it's cleaner than my first "env var" idea (that wouldn't work: this client runs in the browser, so server env never reaches it).

Patch: fix/prompt-user-paced-no-deadline

https://github.com/zoahdev/deepseek-harness/tree/fix/prompt-user-paced-no-deadline

• session.prompt and subagent.prompt are reclassified as caller-signal-only - the same policy the native pickDirectory dialog already uses for user-paced operations. Caller and connection aborts remain; the fixed 30s deadline no longer applies.
• All other unary methods keep their bounded timeout.

Verification

• tsc -b tsconfig.host.json - clean
• fetch-carrier.spec 36/36, including a new regression: a prompt that finishes after 30s resolves with AbortSignal.timeout never invoked

This fixes the occasional signal timed out (internal) under host load without making every RPC unbounded.

[setieroth]

+1。补一份 DSH Desktop 2.0.2（macOS） 的实测，触发面与楼主略有不同：host 并不忙，30s 超时照样误杀。

• 场景：一个超长 session（30,000+ 事件 / 8.4MB zstd / ~66 万 token 上下文，从未 /compact）。GUI 空闲一段时间或长 turn 刚结束后，下一条消息经常 30s 无回音 → signal timed out。
• 关键反证：卡住期间 host 侧完全健康——transcript 里流式按 15~20s/step 稳定推进；且在另一个 turn 运行中直连 webserver 连打 5 次 unary RPC 全部 <1ms。也就是说除了「host 事件循环繁忙」，还有第二个触发面：渲染进程被超大对话拖到饱和（同 Performance: large DSH conversations freeze browser for ~30s (44k DOM nodes / 4.7k SVGs / ~500MB heap) #2724 的 44k DOM nodes / ~500MB heap）。主线程冻结时 fetch 的 promise 无法 settle，30s 后被 AbortSignal.timeout 误杀。
• 恢复模式：重启 App（相当于刷新渲染进程）立刻恢复，DeepSeek 前缀缓存仍是热的（冷启动首 token ~15s）。单日出现 4 轮「卡死→重启」（11:40 / 11:46 / 12:28 / 13:52），全部集中在同一个超大 session；较小 session 无此现象。
• 建议：在 @zoahdev 的 caller-signal-only 分类之外，对 session.prompt 这类发送 RPC 再加一层幂等重试（超时自动重发一次），可把渲染层偶发冻结这类「客户端假死」也吸收掉。另外 host 侧 mux 的 FrameQueue 目前无界——冻结但未断连的客户端会让 host 无限积压流式帧，值得一起加背压。

（AI 辅助生成并代发：由 DeepSeek Harness 内的 agent 基于本机日志与 session transcript 排查后发布，数据与代码行号已核对。）