[Bug][Windows] dsh web 随机静默死亡：node-pty 1.2.0-beta.15 ConPTY socket 无 error 监听 + windowsTerminal 错误处理器 throw

[HarryPD168]

Summary

Windows 上 dsh web 服务器会随机静默死亡（GUI 显示 Failed to fetch (internal)，必须重启）。根因定位在依赖 node-pty 1.2.0-beta.15 的 ConPTY 命名管道 socket：没有挂 'error' 监听（输出端仅在 ready_datapipe 后才挂载）且 windowsTerminal.js 错误处理器里对非 EIO 错误直接 throw err —— 任何一个路径都会产生未捕获异常，把整个 dsh web 宿主进程杀死（所有并行会话/子代理单点全灭）。

Environment

• Windows 11 (19045.4646), Node.js v24.14.0
• dsh 0.1.1-rc.2（npm 全局安装 @deepseek-ai/dsh），web profile
• node-pty 1.2.0-beta.15（dsh\node_modules\node-pty）
• 主机资源充足：32GB 内存，无内存压力事件，无杀毒软件干扰

Symptom

• 高频随机：一天内多次（0:51、1:55、2:22……），总是发生在有 agent 回合在跑的时候（含 4 个并行回合：主会话 + 3 个进程内子代理，同一瞬间全部冻结）。
• 进程死亡方式多样：有时静默（无任何 stderr），有时是标准未捕获异常转储，有时退出码是 -1073741819（0xC0000005 访问违规，原生层）。
• 无 WER 崩溃转储、无事件日志记录 —— 排查难度高，此前用户一直认为是"网络断开"。

Evidence

启动器捕获的进程死亡实录（02:22:13，退出码 1）：

node:events:486
      throw er; // Unhandled 'error' event
      ^

Error: read UNKNOWN
    at Pipe.onStreamRead (node:internal/stream_base_commons:216:20)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -4094,
  code: 'UNKNOWN',
  syscall: 'read'
}

Node.js v24.14.0

另一个运行实例（存活 3 小时）退出码为 -1073741819（0xC0000005，原生访问违规），同样无任何日志输出。

此前的"静默死亡"（监视器每 15s 探测：进程从 http=200 直接变为 NO LISTENER）同样可以在同一时刻的会话文件上看到：多个并行会话的最后一次写入时间完全一致（01:55:43.79），即所有 agent 回合被同一瞬间杀死。

Code analysis (node-pty 1.2.0-beta.15)

调用链：标准预设挂载的持久化 bash/pwsh 工具（dsh-tool-pwsh-persistent / dsh-tool-bash-persistent）→ dsh-terminal-bash → dsh-subprocess-local.spawnTerminal → nodePty.spawn(...)（ConPTY）。

lib/windowsPtyAgent.js 构造函数（约 56-93 行）：

this._outSocket = new net_1.Socket();        // 命名管道 socket（ConPTY 输出）
...
this._outSocket.on('connect', function () {
    _this._outSocket.emit('ready_datapipe');  // 只有到这里之后，
});                                          // windowsTerminal.js 才挂 'error' 监听
var inSocketFD = fs.openSync(term.conin, 'w');
this._inSocket = new net_1.Socket({ fd: inSocketFD, ... });  // 输入侧：从未挂过 'error'

lib/windowsTerminal.js（约 89-105 行）：

_this._socket.on('error', function (err) {
    _this._close();
    if (err.code) {
        if (~err.code.indexOf('errno 5') || ~err.code.indexOf('EIO')) return;
    }
    // Throw anything else.
    if (_this.listeners('error').length < 2) {
        throw err;   // ← 在 'error' 事件处理器里抛出 = 未捕获异常 = 整进程死亡
    }
});

三个独立漏洞，任意一个即可击穿宿主进程：

1. _inSocket（conin 写入侧）从未挂 'error' 监听 → 任何 write/read 错误 = Unhandled 'error' event。
2. _outSocket 的错误监听只在 ready_datapipe 触发后挂载；在此之前 ConPTY 管道断开（如连接超时、worker 失败、子进程被 taskkill）→ 无监听 → 同上。
3. windowsTerminal.js 的 throw err（把错误从 'error' 事件处理器里抛出）。

触发条件（常见于真实环境）：ConPTY 子进程树被杀（taskkill/清理工具/其他 watchdog）、机器息屏唤醒后管道失效、超时回收、_failPtyConnection 竞争。一旦管道断，下一次 read/write 报 read UNKNOWN（errno -4094）即触发。

Impact

• Windows + dsh web 上任何使用持久化终端工具的会话，都可能随机拖垮整个服务器（所有并行会话、子代理、workflow 一起死）。
• 因为进程是"干净"死掉的（无输出/无转储），用户会误以为是网络问题，反复"重启 dsh web 并刷新"。
• Linux/Unix 不受影响（unixTerminal 路径）。

Suggestion

1. windowsPtyAgent.js：构造后立刻给 _outSocket / _inSocket 挂 'error' 监听，统一转发到 _failPtyConnection（失败路径已存在，会触发 terminal exit，宿主可优雅降级）。
2. windowsTerminal.js：移除 throw err（已发生 _close()，错误经 agent onError → terminal exit 传递即可；恢复"抛错"需求时也应收敛到明确错误出口，而不是从 'error' 处理器里 throw）。
3. 升级/更换 node-pty 版本（beta.15 是 beta），或 dsh 侧自行对 PTY 兜底。

本地证据补充：我在本机做了等效验证性修补（上述 1+2，均通过 node --check），修补后 dsh web 不再因该路径崩溃（配合自动重启监视，日志中未再出现 Unhandled 'error' event 崩溃），进一步证实定位。

[HarryPD168]

补充证据（同一台机器，第二次死亡）：

• 发生时机：服务器完全空闲（死亡前后 5 分钟内无任何会话写入/agent 活动）
• 退出码：-2147483645（

[argszero]

Verified against rc.2 (HEAD b150a55) and the exact shipped node-pty artifact (1.2.0-beta.15 pulled from the registry) — your diagnosis is right, and the crash actually has two windows, both fatal to the whole host.

dsh side (rc.2)

• packages/subprocess/subprocess-local/package.json:46 pins "node-pty": "1.2.0-beta.15" — exact match to your environment.
• packages/subprocess/subprocess-local/src/terminal.ts:64-65 — LocalTerminalHandle attaches only onData + onExit; and the public IPty typings (typings/node-pty.d.ts:117-156) expose no error event at all (only onData/onExit/onResize + control methods). There is no interception point on the dsh side — the crash is entirely inside node-pty internals.

node-pty internals (shipped lib/windowsTerminal.js + lib/windowsPtyAgent.js)

• Window A (pre-ready): the ConPTY outSocket is a raw net.Socket created with no error listener (windowsPtyAgent.js:57-58 — only setEncoding), and the socket's 'error' handler is attached only inside the ready_datapipe callback (windowsTerminal.js:67 → :89-90). Any socket error before ready_datapipe fires — connect() failure, pipe break, or the read UNKNOWN in your dump (Pipe.onStreamRead → emitErrorNT) — hits zero listeners, so Node's unhandled-error throw kills the process. Notably the code itself documents this race for the close handler (:55-56 "never fires when connect() fails") — the error handler has the identical exposure, just unremarked.
• Window B (post-ready): the handler at :100-103 is graceful only for EIO (child process closed); any other error falls through to if (this.listeners('error').length < 2) throw err — and since _forwardEvents (lib/terminal.js:90-94) forwards only data+exit (no error), a consumer attaching even one error listener on the terminal still leaves the count below 2. In practice the tripwire is always-throw → uncaught exception → host crash.

So it is not precisely "no listener at all" — it is a conditional listener (installed only on ready_datapipe) plus a throw tripwire that converts non-EIO errors into uncaught exceptions. Both windows kill the entire host, which is exactly why your four parallel sessions froze at the same instant.

Family: this is the 4th member of the connection-lifecycle family I have been tracking (#4059 webserver upgrade-socket error listener removed during teardown over-cleanup → delayed ECONNRESET unhandled → crash; #4073 LSP stdout no error listener → crash; now #4436). Same invariant every time: a socket/stream whose 'error' listener is absent, conditional, or removed → Node's unhandled-error throw kills the whole process, and the blast radius is always "one socket kills every concurrent session."

Fix directions

1. Root cause belongs in microsoft/node-pty upstream: attach the socket 'error' listener at construction (outside the ready_datapipe callback) and replace the <2 listeners → throw tripwire with emit('exit') + close + log. There is no fixed release to upgrade to — npm dist-tags show beta = 1.2.0-beta.15 (newest) while stable latest = 1.1.0 is older than the beta line; and dsh cannot patch node_modules (native addon, patches lost on every reinstall, fresh installs still pull 1.2.0-beta.15).
2. dsh defense-in-depth: app-boot has no uncaughtException handler (the same gap I flagged on Bug: LSP server stdout has no error listener — one transport failure crashes the whole host process #4073) — a scoped handler that logs and continues would convert these host deaths into recoverable failures. It must be a deliberate design choice (not a silent catch-all), with terminal/session cleanup semantics defined.
3. Interim: keep node-pty's beta line on the watchlist; if you can open the upstream PR, I am happy to draft the hunk (error listener at construction + emit('exit') instead of throw).

[dong-victor]

太频繁了, 这样很难用啊