[Bug] Desktop host 进程因未捕获的 ECONNRESET 异常退出后 web 服务不自恢复（UI 假活、端口全断）

[wan0791]

环境 / Environment: @deepseek-ai/dsh-desktop 0.2.0-rc.2 / Windows 11 x64 / Electron 44.0.0 / Node 24.18.1

现象 / Symptom: 应用运行 1-2 小时后，dsh host 进程因未捕获异常退出。crash log 记录：

dsh: fatal uncaught exception: Error: read ECONNRESET
    at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:87:19)
    ...
    at ChildProcess.<anonymous> (file:///D:/DeepSeek%20Harness/resources/app.asar/lib/main.js:3724:64)
    at ChildProcess._handle.onexit (node:child_process:1124:15)

退出后 Electron 壳进程继续存活，但：

• 127.0.0.1 web 服务端口消失
• dsh-dock 远程访问网关（mobile-relay）随之全断
• UI 无任何错误提示，界面上看不出异常，只能手动重启应用恢复

频率 / Frequency: 2 天内发生 3 次（10/09 一次，10/16 两次），均发生在正常使用期间（有活跃会话和插件运行），非空闲挂机。三次同一模式：read ECONNRESET（其中一次 write ECONNRESET）在 ChildProcess stdio 回调中未捕获，升级为 fatal uncaught exception。

影响 / Impact: 在 Windows 上把 Desktop 作为本地 agent 节点持续使用时完全不可靠——崩溃后应用"假活"（进程在、服务全断、界面无提示），无人值守场景无法自愈，必须手动重启。

期望 / Expected:

1. host 对子进程 stdio 管道的 ECONNRESET 类错误做捕获，不升级为 fatal uncaught exception（网络抖动/客户端断开不应杀死 host）
2. host 进程意外退出后能自动重启，或至少在 UI 上显式报错并提供一键重启入口

日志说明: 本机存有 3 份完整 crash-*.log（crash-2026-10-09T10-23-31-720Z-host.log 等，位于 %APPDATA%@deepseek-ai\dsh-desktop\logs\），已确认不含 API key/凭据，需要完整日志可以继续补充。

---

EN summary: Desktop host process crashes on an uncaught ECONNRESET in a ChildProcess stdio callback (main.js:3724). After the crash the Electron shell keeps running but the loopback web server and the dsh-dock mobile-relay gateway stay dead, with no UI indication — only a manual restart recovers. 3 occurrences in 2 days (10/09, 10/16 x2), all during normal use with active sessions/plugins. Request: catch stdio pipe errors instead of letting them escalate to a fatal uncaught exception, and auto-restart the host or surface the failure in the UI.

/cc @deepseek-ai

[argszero]

Thanks — the trace plus the frequency data is enough to locate this, and one part of your first request already has a named precedent in the tree. Two things are worth separating, because they have different answers.

1. The bug is that ECONNRESET reaches the process-level handler at all — not the fatal policy

The harness installs its fail-loud handler for uncaughtException deliberately, and the reasoning is written down in .agents/notes/implemented/architecture/2026-09-22-fatal-diagnostics-and-crash-reports.md:

Uncaught exceptions are fatal and reported; the failed operation is never resumed. ... only the throw site knows which state is intact; a 'data' listener that threw mid-update has already dropped a chunk and half-set its own fields, and resuming would turn a visible crash into silently wrong output.

The implementation is installFailLoud (packages/boot/app-boot/src/index.ts:884): the exception arm at :925 ('fatal uncaught exception'), registered at :931. The desktop host receives it from the profile boot (apps/cli/src/profile-boot.ts:309, with the release hook set to fiber.dispose()). So "catch it inside that handler and carry on" is not the change to ask for. The fix is one layer down: a pipe error event must never be emitted with no listener attached.

That is exactly what this codebase already does in one place — packages/experimental/ptc-runtime-python/src/index.ts:2318–:2324:

// Fd-3 and the stdout/stderr pipes emit `error` on early child death
// (ECONNRESET/EPIPE); swallow them so they do not become uncaught. The
// authoritative failure signal is `child.on('close')` above.
const silenceStreamError = (): void => {}
proto.on('error', silenceStreamError)
child.stdout.on('error', silenceStreamError)
child.stderr.on('error', silenceStreamError)

A whole-tree search for a stdio error listener finds one in seven files. Only one of them is the harness's own subprocess layer, and there the guard covers stdin only — packages/subprocess/subprocess-local/src/spawn.ts:385, justified in the comment by "batch stdin is written up front; process exit and captured output remain authoritative". The stdout/stderr collectors have no listener at all. Your trace is the write/read completing after the child has already died (WriteWrap.onWriteComplete ← ChildProcess._handle.onexit), which is precisely the shape the ptc-runtime comment describes. The narrow fix is therefore silenceStreamError on the collected pipes in the subprocess layer, leaving child.on('close') as the authoritative outcome — the same contract, applied one layer up from where it already exists.

2. There is no respawn today, and that is structural

DesktopHostProcess.start() returns the existing promise whenever a child already exists (apps/desktop/src/host-process.ts:187), and apps/desktop/src/main.ts:447 is the only construction site for the class. After the host child exits, nothing in the shell can spawn a replacement — start() is a permanent no-op. That is why "the Electron shell keeps running while the port is gone" is exactly the shape you observe.

But a completely silent UI is not what the current code should produce, and that half deserves one more datum. Two independent reporters exist, and they cover different regimes:

• The host's startup failure path sends a {type: 'fatal', message, diagnostic} frame (apps/desktop-host/src/index.ts:117), which the shell converts into DesktopHostFatalError (apps/desktop/src/host-process.ts:218). That frame is reachable only from main().catch at :111 — startup only.
• An uncaught exception after startup goes through the fail-loud handler described above: one util.inspect diagnostic to stderr, release, exit(1). No fatal frame is sent in that case. The shell learns from child.once('close') (host-process.ts:227), which builds dsh desktop host exited with <code>: <stderr tail> (:229) out of the last 64 KiB of stderr (:51, :204) — and that error is what feeds the native recovery dialog and the crash report.

So: did a native dialog appear? And was the window that looked alive the Electron window, or a browser client of the loopback port? If the answer is "no dialog at all", that is its own defect — a post-startup fatal that the shell does not surface — and I have not confirmed that path fires for a pipe-death exception specifically. Since you offered, the crash-*.log files would settle it: the diagnostic in them is util.inspect of the error, so if the last one contains fatal uncaught exception with the ECONNRESET, the fail-loud path ran and its stderr output is exactly what the shell read.

On the plugin side

The emitter is in the harness's own subprocess layer, and that layer has a mountable seam: a plugin can shadow the subprocess service instance, which is the same technique our published @argszero/dsh-codex-wire-capture uses to tee child stdio. A stopgap that wraps the service and attaches error listeners to each child's stdio before handing it back is buildable without an upstream change. I am packaging that, and will reply here with the package once it is on npm — but the core fix above is still the right one, and the plugin only stops the escalation, it does not restore the dead host.

[argszero]

Following up on my earlier reply, as promised: this is now a shipped plugin.

• npm: @argszero/dsh-stdio-error-guard@0.1.0
• source / README: https://github.com/argszero/dsh-stdio-error-guard

- insert:
    - id: stdio-error-guard
      name: '@argszero/dsh-stdio-error-guard'
      inject:
        - subprocess

The layer looks covered, and is not

I want to correct the emphasis of my first reply, because measuring it changed what the gap actually is.

The subprocess provider does attach an error listener to a child's piped streams. observeOutputStream (packages/subprocess/subprocess-local/src/spawn.ts:293) registers once('end'), once('close') and once('error'), and its settle removes all three the moment the first of them fires (:296-305).

An ordinary child exit ends the pipe. From that instant the stream carries no listener at all, and a pipe error arriving afterwards is thrown out of the libuv completion with nothing to catch it — which is exactly the shape of your stack (at ChildProcess._handle.onexit).

I measured both directions against the shipped modules (@deepseek-ai/dsh-subprocess-local@0.2.1-alpha.2, a real cordis Context, a real child), so this is not inference:

	stdout.listenerCount('error') after the child closed	stdout.emit('error', ECONNRESET)
provider alone	0	throws read ECONNRESET
with this plugin mounted	1	inert, and the caller's own reader still receives every byte

So the window is not "the collector forgot to listen" — it is "the listener was a once and the child's close consumed it". That is a one-line-shaped difference, and it is why a fix belongs in the provider; see below.

What the plugin does

It shadows the subprocess service's spawn and spawnTerminal — one own-property write on the instance behind the tracking view, which both methods being prototype methods is what makes process-wide — and attaches one inert, persistent on('error') to each stream the handle exposes: stdin, stdout, stderr, control on a child, output on a terminal. The persistent on is the entire point: it outlives the provider's once and covers the post-close window.

Nothing else changes: no spec, no argv, no environment, no byte consumed, no listener replaced or suppressed, the stream is not destroyed or resumed, and the handle you receive is the provider's own object, un-wrapped. The prototype itself is never mutated, and disposal deletes the own property to reveal it again.

Every occurrence is counted per stream and the first of each distinct error.code is reported — one broken pipe reaches the log, a child that fails a thousand times does not fill it.

config:
  enabled: true   # false installs nothing at all
  log: warn       # silent | debug | warn

What it deliberately does not do

• It does not change the fatal policy. installFailLoud is right for a throw mid-update, and the architecture note's reason still holds. The claim is narrower: a pipe error on a child that already exited should never have been emitted with no listener, so it never reaches that policy in the first place.
• It cannot restore a host that already died, and it adds no respawn. That is still structurally absent upstream (apps/desktop/src/host-process.ts:187 returns the existing promise whenever a child exists; main.ts:447 is the only construction site). This prevents the death; it does not resurrect.
• Collect-mode streams are invisible to it — a SubprocessCollect child's pipes are bound inside bindManagedProcess (spawn.ts:288) and no plugin ever sees them.
• The shell's own pipes are in a process that mounts no plugins — host-process.ts:203-205, command-manager-entry.ts:29, login-shell-environment.ts:114-115. Those stay your surface.

The durable fix, and why this is still worth shipping

In the provider: observeOutputStream should leave a permanent listener on a piped stream it has finished observing, instead of a once that settle strips. The tree already contains that contract for the Python worker child — ptc-runtime-python/src/index.ts:2318-2324 registers an inert handler on fd-3, stdout and stderr with the comment "swallow them so they do not become uncaught. The authoritative failure signal is child.on('close') above." This plugin is that same contract applied one layer up, to every child the service starts, for deployments that cannot wait for a release.

Verification

• 93 tests / 19 suites. Eight of them run against the shipped modules rather than a stand-in, including the both-directions measurement in the table above.
• 23 defect-injection arms, 23 caught, zero silent (npm run test:inject mutates, rebuilds with tsc, requires the suite to go red). One arm per distinction: the listener itself, the de-duplication mark, the per-code economy, the tally, the slot classification, the instance-vs-view landing, the write read-back, the unwinding, the four config decisions, and the two paths that must not manufacture an unhandled rejection.
• Zero runtime dependencies; cordis and dsh-subprocess are peers.

If it turns out your ECONNRESET is on a collect-mode stream or inside the shell process, this plugin will not cover it — tell me which, and I will say plainly whether it is reachable from a plugin at all.

[argszero]

Publication status update: @argszero/dsh-stdio-error-guard@0.1.0 is on the registry, so the mitigation described in my earlier reply can now be installed instead of read.

Verified through the registry's own version endpoint (not the client's exit code):

• dist.shasum = 65e42e27f967b59b1bae7fcb41352e78f1162d2f
• gitHead = c285aae38175ec6da51cd8fd9009edb8ea22270c
• source: https://github.com/argszero/dsh-stdio-error-guard

dsh plugin add @argszero/dsh-stdio-error-guard

What it does, in the terms of this report: the backend does register terminal listeners on each stdio handle (spawn.ts:293), but settle (:296-305) removes all of them on the first end/close/error, so after that point the handle has zero listeners and the next ECONNRESET reaches Node's uncaught path. The plugin keeps one persistent on listener per handle for the lifetime of the handle, so that error is consumed exactly where it arrives instead of arriving at the host's fatal handler. It changes no exit policy: a host that dies from a real defect still dies.

One honest limit: it cannot make the failure loud on stderr — that sink is owned by the host, not by a plugin.