[Bug] Desktop 0.2.1-rc.2: enabling the experimental "Developer tools" can crash the host after its inspector source closes — "inspector: Host source is closed"

[CNyaotian-Lunar]

Desktop 0.2.1-rc.2：开启实验性「开发者工具」后，inspector 源关闭会让 host 崩溃 — inspector: Host source is closed

摘要

设置 → 实验性插件 → 打开「开发者工具」（@deepseek-ai/dsh-experimental-inspector-profile）之后，HostInspectorSource 一旦被关闭（异常协议帧 / 异常 disposal），Cordis 树观察者没有被停掉，下一次树变化会在 HostBridgePublisher.setState() 抛出未捕获异常并终止 host。

严重度：P1，不是 P0。触发需要先发生一次「source 被关闭」；正常 disposal 路径是逆序的（观察者先 dispose、transport 最后关），不会触发。

本文在初版基础上做了更正：初版写「3/3 稳定复现 / P0」，经两路独立复核后降级（见文末「更正说明」）。

环境

• DSH Desktop 0.2.1-rc.2（Windows 11 x64，官方安装包）
• Electron 44.7.0 / Node 24.21.0
• profile：desktop

现象

• 用户侧共触发 3 次（打开「开发者工具」后使用，host 退出、应用弹 "The application could not start or stopped unexpectedly."）。
• 落盘证据只有 1 份：%APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-17T20-07-55-901Z-host.log（phase: running）。另外两次没有生成对应的 crash-*-host.log。

崩溃日志（节选）：

dsh: fatal uncaught exception: Error: inspector: Host source is closed
    at HostBridgePublisher.setState (...\dsh-experimental-inspector\lib\index.js:1108:26)
    at HostInspectorSource.setState (...\lib\index.js:836:18)
    at ...\lib\index.js:2322:13
    at publish (...\lib\index.js:2294:3)

注意：栈底 main.js:3844 属于 Electron 主进程记录崩溃的 child.once('close') handler，不在 host 子进程的调用链里。

源码链

① setState() 在 closed 时 throw，而不是丢弃

setState(topic, payload, monotonicMs = performance.now()): void {
  if (this.closed) throw new Error('inspector: Host source is closed')
  ...
}

② close() 把 publisher 标记为 closed

close(): void {
  this.publisher.close()        // → HostBridgePublisher.closed = true (:1140)
  this.closed = true

③ Cordis 树的观察者没有和 source 生命周期绑定

function publishCordisTree(ctx, publisher, limits) {
  return observeCordisTree(ctx, (snapshot) => {
    publisher.setState(CORDIS_TREE_TOPIC, snapshot)   // 不判断 closed
  }, limits)
}

④ 异常后续

setState 的 throw 发生在微任务里，没有 catch ⇒ uncaught exception ⇒ installFailLoud ⇒ exit(1)。

触发条件（重要）

• 正常 disposal：观察者先被 dispose，transport 最后关闭 ⇒ 安全。
• 异常关闭（运行期有两条非 dispose 路径）：
  1. HostInspectorSource 的 port.on('message') catch 会直接 this.close()（transport.ts 的 catch { this.close() }，无日志）——本次崩溃最可能的路径；
  2. worker 意外退出清理（lib:1886-1896）同样会关 source、留下活观察者；本次因有日志可排除。
     两条路径之后，下一次 Cordis 树变化就撞上 setState 的 throw。
• 因此「打开开关」只是武装链条；真正引爆需要一次协议级异常（坏帧 / ack 不匹配 / misroute）。

⚠️ 这条推断是从代码推出来的（C 级）：崩溃日志没有记录那条坏帧（catch 完全静默），要直证需要临时加日志复现。

版本差异

tag	packages/experimental/inspector	inspector-profile	用户能开吗
dsh-v0.2.0-rc.2 (639ed01)	有	无	不能（设置页不出现）
dsh-v0.2.1-rc.2 (687f282)	有（publisher / transport 与前者逐字相同）	有	能

即：旧缺陷 + 新入口。上游 master（687f282）这两段实现未变。

期望

1. disposal，而不是 silence：close() 时释放 publishCordisTree 的订阅（observeCordisTree 本来就返回 disposer）。注意两处缺口：
   • startInspector 的 markRunning（lib:1886-1896）可能在观察者注册之前就关掉 source ⇒ 注册时要检查 source.closed；
   • port.on('close') 只 queries.disconnect()，不关 publisher/source ⇒ 要把 port close 也纳入释放。
2. 不要改成「静默丢弃」：setState 在 closed 时 return 会让观察者永久活着、持续跑全树 snapshot() —— 那是永久成本，不是修复。
3. 不要试图改全局 fail-loud：installFailLoud 的 latch / release / exit 是刻意的；可行的是在回调边界内兜底（也就是第 1 条）。

更正说明

初版对外写的是「打开开关 3/3 稳定崩溃，P0」。两路独立复核后更正：

• 4 份 host 崩溃日志里只有 1 份（20:07:55，phase: running）含 inspector 栈；另外 3 份是 phase: startup，根因是 dsh-desktop-host 的 INACTIVE_EFFECT 与 connection 缺 webRuntime，与 inspector 无关。
• 用户侧确实触发过 3 次，但只有 1 次落盘；「3/3 稳定复现」不能作为日志证据。
• 严重度从 P0 降为 P1：需要先发生一次 source 关闭，之后才必然引爆。
• 采纳反馈后进一步修正：setState 静默丢弃不是修复（会留下永久全树 snapshot 成本）⇒ 改为 disposal；「改全局 fail-loud」不可行，回调内兜底保留；「唯一非 teardown 调用者」的说法不成立（worker 意外退出是第二条）。

相关

• [Bug] Inspector Cordis-tree growth crashes Desktop Host: source state exceeds source-frame byte limit #9271 同一模块的另一条崩溃路径（source state 超过 source-frame 字节上限）。

---

English summary

Symptom. After enabling the experimental "Developer tools" (@deepseek-ai/dsh-experimental-inspector-profile) on Desktop 0.2.1-rc.2, the host can die with fatal uncaught exception: Error: inspector: Host source is closed (one crash log captured at 20:07:55, phase: running; the user reports three occurrences in total).

Root cause. HostBridgePublisher.setState() throws when closed instead of dropping the update; publishCordisTree() keeps observing the Cordis tree without binding to the source lifecycle, so once the source is closed (e.g. the silent catch { this.close() } on a bad worker frame) the next tree change throws in a microtask with no catch and terminates the host (installFailLoud → exit(1)). Normal disposal is safe because the observer is disposed first.

Severity: P1, not P0. The switch arms the chain; a protocol-level anomaly is still required to close the source. The first version of this report claimed "3/3, P0" — that was corrected after independent review: only one of the four host crash logs contains the inspector stack, the other three are startup failures caused by missing webRuntime.

Version note. The throwing code is identical in dsh-v0.2.0-rc.2; 0.2.1 only added the inspector-profile entry bundle (old defect, newly exposed). Upstream master is unchanged.

Suggested fix. Stop observation on close, make setState drop silently like publish, and at minimum downgrade the uncaught exception to a failure of this plugin instead of terminating the host.

[argszero]

The chain holds at 687f282e86, and your version note is right — I checked both halves rather than taking them: dsh-v0.2.0-rc.2 already carries the throwing setState verbatim (git show dsh-v0.2.0-rc.2:packages/experimental/inspector/src/host/bridge/publisher.ts), and packages/experimental/inspector-profile does not exist at that tag (git ls-tree) while it does on master. Old defect, new entry, confirmed.

Confirmed as written. publish() returns when closed (src/host/bridge/publisher.ts:24) while setState() throws (:31); the tree listener calls setState with no closed check (src/shared/cordis/publisher.ts:22-23); the observer's own closed flag is set only by its disposer (src/shared/cordis/observer.ts:27, :31, :40-44), so it keeps scheduling after the publisher is closed and the throw happens inside queueMicrotask(publish) with no catch above it. HostInspectorSource.close() closes the publisher first and marks itself second (src/host/bridge/transport.ts:64-67), and the only non-teardown caller is the silent catch { this.close() } in the message handler (:43-48), which has no logger — so your "C-level, inferred from code" label is the honest ceiling from the log alone.

Teardown order is safe, as you said — and worth pinning in the thread: disposeInspectorResources runs the registration disposers in reverse and closes the transport last (src/shared/dispose.ts:15), and the tree observer is registered well before the worker is closed (src/host/plugin.ts:62, :80-83). That is why the crash needs one abnormal close first, and it is a good argument for keeping the severity where you put it (P1, not P0).

One correction to your fix 2. "Make setState drop silently like publish" removes the crash and leaves a permanent cost: the observation is still live, so every internal/plugin and internal/status event still runs collector.snapshot() — a bounded but real full walk of the Cordis tree (maxCordisNodes, maxSourceFrameBytes - 4096) — and throws the result away, for the rest of the process's life. The right shape is disposal, not silence: the publisher interface (InspectorStatePublisher) exposes no closed state to consult, so either add one, or let HostInspectorSource own the observation and release it in the same step as close(). observeCordisTree already returns exactly that disposer, so this is a lifetime bug, not a missing privacy check.

On your fix 3. "Downgrade the uncaught exception to a failure of this plugin" is not available, and not by accident — the host's fail-loud path is deliberate, because a host that survives a fatal error by staying quiet is worse to diagnose than one that stops. So the burden falls entirely on the weaker rule: a callback whose lifetime you do not own must not throw. That is fix 1, and it is the whole fix.

Turning your C into an A, cheaply. The silent catch is what blocks attribution. Give close() a reason argument and log it there, or log inside the catch before closing — one line, no behaviour change, and the next occurrence stops being an inference. I would send that with the fix, since a second crash with the same signature would otherwise be just as unattributable as this one.

Plugin-mountability: none. The observer is created inside the same plugin against handle.source directly (src/host/plugin.ts:80), not through the ctx.inspector service, so a third party has no seam to interpose between the tree and the publisher. This belongs in packages/experimental/inspector.

Finally, the correction you already made is the most useful part of the report: distinguishing the three phase: startup logs from the one phase: running log is what turns "3/3, P0" into a chain that a reader can act on. If you can attach the startup failures to the INACTIVE_EFFECT / missing-webRuntime cause in a separate report, that would be worth its own thread — it is a different defect that happens to share a symptom.

[CNyaotian-Lunar]

@argszero 感谢仔细核对 —— disposal 的方向和 fail-loud 的代码依据都帮我们把结论收紧了，这两条比我们原来的方案准。下面是复核后的两处收紧（我们自己另拉了一路核对，不是照单全收）：

中文

• 「唯一非 teardown 关源路径」不成立：worker 意外退出清理（lib:1886-1896）是第二条同样会"关 source、留下活观察者"的路径；本次因有日志可排除，但作为全局断言是错的。
• disposal 要补两个缺口：① startInspector 的 markRunning 可能在观察者注册之前就关掉 source ⇒ 注册时要检查 source.closed；② port.on('close') 只 queries.disconnect()，不关 publisher/source ⇒ port close 要纳入释放。
• fail-loud：「刻意」有代码依据（latch / release / exit），但「不可用」只对改全局 handler 成立；回调边界内兜底仍是可行的，也就是 fix 1。
• 行号小偏差：publisher.ts:24 的 return 实际在 25；observer.ts:27/31 是读取点、设值在 42。

English

Thanks — the disposal direction and the code-backed fail-loud reading tightened our conclusions; both are better than our original suggestions. Two refinements after an independent review on our side (we did not take it on trust):

• "The only non-teardown close path" is not true: the worker-exit cleanup (lib:1886-1896) is a second path that closes the source and leaves the observer alive. It is excludable in this incident only because it logs.
• Disposal needs two more gaps covered: (1) startInspector's markRunning can close the source before the observer is registered, so registration must check source.closed; (2) port.on('close') only calls queries.disconnect() and never closes publisher/source, so port close must be part of the release.
• Fail-loud: "deliberate" is code-backed (latch / release / exit), but "not available" only holds for changing the global handler; catching at the callback boundary remains valid — that is fix 1.
• Line numbers: the publisher.ts:24 return is actually at 25; observer.ts:27/31 are read points, the assignment is at 42.

[JHees]

感谢主贴和复核。补一条新的现场证据：确认复核里说"本次因有日志可排除"的第二条关闭路径
（worker 意外退出清理）在真实使用中就是触发者，并定位到它的 socket 级原因。

现象与日志

• DSH Desktop 0.2.1-rc.2（Windows 11 x64，官方安装包），Electron 44.7.0 / Node 24.21.0，desktop profile，
  Inspector 由 @deepseek-ai/dsh-experimental-inspector-profile 默认启用。

• 两次 phase: running 崩溃（本机时间 01:32:47、01:49:33），栈与主贴一致：
  HostBridgePublisher.setState → HostInspectorSource.setState → publishCordisTree → microtask → exit(1)。

• 与本帖事故的区别：这两份 host stderr 在 fatal 前都有——

  dsh inspector: Worker stopped unexpectedly Error: read ECONNRESET
      at TCP.onStreamRead (node:internal/stream_base_commons:216:20) { errno: -4077, code: 'ECONNRESET', syscall: 'read' }
  

  也就是 startInspector 的 markRunning 回调（controller.ts:265-275）关掉了 source。
  两次崩溃都是这条路径，它不是边缘情况。

Worker 为什么会 ECONNRESET

worker/bridge/endpoint.ts 的 handleUpgrade(request, socket, head) 拿到的是裸 socket。
Node 的 HTTP server 在 server.emit('upgrade', req, socket, head) 之前会移除自己的 error 监听
（Node v24 lib/_http_server.js:1047：socket.removeListener('error', socketOnError)）。之后：

• 400/403 分支只做 socket.end(...)，没有挂 socket.on('error', ...)；
• 交给 ws 的分支在握手完成前（ws.handleUpgrade 早期/abort）也还没有 WebSocket 对象上的 error 监听；
• 兜底 socket.destroy() 分支同理。

浏览器端 Inspector/Client 连接异常断开（页面重载、DevTools 重连）时，原始 socket 的
read ECONNRESET 就是 Worker 线程里的未捕获错误 → Worker 退出 → markRunning 关闭 source、
观察者仍然活着 → 下一个 internal/plugin / internal/status 微任务撞上 setState 的 throw →
host exit(1)。日志没有逐连接记录，所以具体命中哪个分支（400/403/ws abort）无法从现有日志归因，
但未处理点就是这一个入口。

补充证据：worker 死后 host 是"已上膛"的

同一实例上观察到的运行期状态：Worker 已死后 127.0.0.1:9230 已无监听，
而 Chromium 网络进程仍每几秒向 9230 发 SYN_SENT（Client 在按 reconnect 退避重试）；
host 在 Worker 死后 8–16 分钟仍存活，然后在下一批 Cordis 状态事件上崩。
即 worker 一死，"可能崩"就变成"迟早崩"——这支持把"别让 Worker 线程死"当作第一道修复，
而 disposal 修复是第二道。

建议补丁（socket 层，与主贴的 disposal 修复互补）

--- a/packages/experimental/inspector/src/worker/bridge/endpoint.ts
+++ b/packages/experimental/inspector/src/worker/bridge/endpoint.ts
@@
   private handleUpgrade(request: IncomingMessage, socket: Duplex, head: Buffer): void {
+    // node:http detaches its own socket error listener before emitting 'upgrade'
+    // (lib/_http_server.js: socket.removeListener('error', socketOnError)). The
+    // rejection branches below answer with socket.end() and never attach a handler,
+    // and ws owns the socket only after a completed handshake, so an abrupt client
+    // reset currently kills the Worker thread. Retain the process here.
+    socket.on('error', () => {})
     let url: URL

回归测试思路：用 port: 0 起 endpoint，裸 TCP 客户端发一个非法 upgrade 路径后立刻 RST
（SO_LINGER = 0），断言 Worker 仍能响应 /json/version，即线程没被 socket error 打死。

本地处置（打包版无法改 asar）

桌面 profile 的 patch 层禁用两行后稳定：重启后 8 分钟以上无新崩溃日志，且 :9230 再无任何连接。

- id: experimental-inspector
  name: "@deepseek-ai/dsh-experimental-inspector"
  disabled: true
- id: session-inspector
  name: "@deepseek-ai/dsh-experimental-session-inspector"
  disabled: true

English summary

I can confirm the second close path you flagged in the review is not hypothetical: two phase: running
crashes on Desktop 0.2.1-rc.2 (Windows 11 x64) show dsh inspector: Worker stopped unexpectedly Error: read ECONNRESET
in host stderr immediately before the fatal inspector: Host source is closed microtask throw, i.e. the
markRunning cleanup (controller.ts:265-275) closed the source and left the Cordis observer alive.

The Worker death is a raw-socket problem: node:http removes its own error listener before emitting
'upgrade' (Node v24 lib/_http_server.js:1047), and InspectorEndpoint.handleUpgrade never attaches one —
not on the 400/403 socket.end() branches, not on the destroy() fallback, and ws owns the socket only after
a completed handshake. An abrupt client reset therefore becomes an uncaught ECONNRESET in the Worker thread.
Which exact branch received the reset cannot be attributed from the log (no per-connection logging).

Operational note: after the Worker dies the Host stays alive with a closed source and a live observer;
the Inspector endpoint is gone (:9230 not listening) while the browser client keeps retrying SYN_SENT,
and the Host crashes 8–16 minutes later on the next internal/status event. So the Worker-death fix matters
independently of the disposal fix.

Suggested one-line hardening at the top of handleUpgrade:

   private handleUpgrade(request: IncomingMessage, socket: Duplex, head: Buffer): void {
+    socket.on('error', () => {})
     let url: URL

Regression test: bind with port: 0, send an invalid upgrade path from a raw TCP client and reset it
(SO_LINGER = 0), then assert /json/version still answers (the Worker thread survived).

Local workaround: disabling experimental-inspector and session-inspector in the desktop profile's
cordis.patch.yml is stable after a restart (no new crash logs; no connections to :9230).

Note: the diff above was prepared against master but not executed in the monorepo test suite — the
observation came from a packaged desktop build, so please treat it as an untested suggestion.