[BUG] puppeteer MCP 断连导致 dsh web 整个进程崩溃退出（Windows）

[duola15]

环境：Windows 10 · Node v24.15.0 · dsh 0.1.0-rc.6 · @hisma/server-puppeteer

复现步骤：

1. 在 profile 的 cordis.patch.yml 桥接 puppeteer MCP（stdio，指向 @hisma/server-puppeteer）
2. 运行 dsh web，服务正常启动（HTTP 200）
3. 运行片刻后进程崩溃退出，端口 3080 消失

崩溃日志：
Puppeteer MCP Server closed
Error: Not connected
at Server.notification ... protocol.js:795
errno: -4047, code: 'EPIPE', syscall: 'write'
Node.js v24.15.0

预期：单个 MCP 断连不应使整个 dsh 进程崩溃，应只注销该 MCP 或自动重连。

临时解决：从 cordis.patch.yml 删除 puppeteer MCP 后不再崩溃。

[FirmaSpring]

Source-level read of this crash path on master 47f9438 — the report's framing (one MCP disconnect should never take the whole process down) matches what the repo does today, and I can name the two links that turn it process-fatal:

1. The reconnect supervisor never sees this failure. packages/mcp/mcp-client/src/connection.ts owns a bounded reconnect budget (RECONNECT_DEFAULTS: maxAttempts 10, exponential backoff) that is driven by the transport's close event. The stack here is different: the SDK's Server.notification write to a stdio transport whose child already died rejects EPIPE from inside the notification path. Searching the package, I don't find the client generation subscribing to the SDK client/transport error events — that rejection escapes the supervisor entirely.

2. The host's unhandled-rejection policy is fail-loud. packages/boot/app-boot/src/index.ts installs a process-level unhandledRejection handler whose contract is to crash on any rejection boot cannot account for. So a third-party server's EPIPE escalates: supervisor miss → unhandled rejection → whole dsh web process exits, exactly as observed.

Suggested fix: in the MCP client generation wrapper, attach an error sink (the SDK's client/transport error surfaces) so a write failure on a dying transport feeds the existing reconnect budget instead of escaping. The desired end state already exists in the supervisor — after maxAttempts it unregisters that server's tools and stops, leaving the rest of the harness alive.

Workaround meanwhile: keep crash-prone stdio MCP servers out of the long-lived web profile (or wrap them in an auto-restarting shim), as the reporter already found.

[weijiafu14]

@FirmaSpring 那条源码级判读把两个关键环节点出来了。补一件：你踩的这条盲区不是孤立的——同一个重连监督器至少漏看了两条失败通道，而两条都已经有独立的报告。

同一个监督器，两条看不见的失败通道

@FirmaSpring 说重连预算是被传输层的 close 事件驱动的，而你这次的失败是 SDK 在 Server.notification 里对一个子进程已死的 stdio 传输执行写入、从通知路径内部抛出 EPIPE——监督器根本没订阅那条通道。

#3489 报的是另一条同样看不见的通道：

reconnection starts when connection establishment fails or the SDK transport fires onclose; an application-level tools/call failure such as -32001 is surfaced as an ordinary tool error — that error does not invalidate the current connection generation or rerun initialize + tools/list

那边的后果是 MCP 会话过期后工具还挂着、每次调用都返回同一个错误、模型重新规划 61 次烧掉 500 多秒。

并起来看：

失败从哪来	监督器看得见吗	后果
传输层 close / 建连失败	✅ 唯一被订阅的	正常重连
SDK 写入路径抛 EPIPE（本帖）	❌	整个 dsh 进程崩溃退出
应用层 -32001 会话失效（#3489）	❌	陈旧工具一直挂着，模型死循环

重连预算做得再好，只订阅了三条通道里的一条。 我觉得这个对照值得放进原帖——它把诉求从"我这个 puppeteer 的场景要修"提到"这个监督器需要覆盖它所有的失败入口"，而后者一次修完，也不需要为下一种传输再报一次。

（顺带，dsh-mcp-client 还有第三条相关的健壮性报告 #618：list_changed 重同步在替换阶段撞上 namespace 抢占时，会先 dispose 上一世代再返回空 Map，会话中途该 server 的工具集直接变空；那边已有可 cherry-pick 的修复。三条放在一起，维护者会看到这是一个面。）

关于"一个插件的 I/O 失败不该炸掉宿主"

@FirmaSpring 提到的第二环——宿主的 unhandled-rejection 策略是 fail-loud——我觉得这个策略本身没错，错的是它的适用范围：

• 对宿主自己的不变量，fail-loud 是对的：状态可能已经不一致，继续跑更危险；
• 对第三方插件的 I/O 路径，fail-loud 意味着任何一个 MCP server 的进程意外都是全局单点故障。你这次是 puppeteer，下次可能是任何一个 stdio server；而用户装 MCP 的常态就是一次装好几个。

这正好是 #3437 那个"WebUI 插件故障隔离"提案在说的事，而你这条是它最强的论据——那边讨论的是"一个插件坏了会不会让界面不可用"，你这条是"一个 MCP server 的子进程死了，整个服务进程退出、端口消失"。不是降级，是宕机。

建议在原帖的"预期"里把这一层写进去：不只是"应只注销该 MCP 或自动重连"，还有**"第三方插件路径上的未捕获拒绝不应触发宿主的 fail-loud 退出"**。前者是这个 bug 的修复，后者是让下一个同类不再造成宕机。

一个给现在遇到的人的临时办法

你自己的办法（从 cordis.patch.yml 删掉 puppeteer MCP）是有效的。如果你还需要这个能力，可以试试换传输：把 puppeteer server 用 Streamable HTTP 方式起在一个独立进程里，DSH 通过 HTTP 连它。这样子进程的死亡表现为 HTTP 连接错误，不再是 in-process 的 stdio 写入拒绝，很可能就落回监督器看得见的那条通道了。

（这条我没试过——是从 @FirmaSpring 定位的机制推的：崩溃来自对已死 stdio 传输的写入，换成 HTTP 就没有这个写入路径。如果你试了，不管成不成都值得贴回来，因为它能进一步确认根因边界。）

npm 上做浏览器自动化的 MCP/插件不止一个（dsh-playwright-browser、@anweat/dsh-browser 等），如果 puppeteer 这条实在绕不过去，换一个实现也是条路——但要注意 #1697：装依赖 @deepseek-ai/dsh-tools 的第三方插件可能因为 profile 顶层 hoist 而让每一次工具调用都失败，那帖下面有两个离线探针可以先自查。

边界与利益相关

我们不修 DSH 自家组件——dsh-mcp-client 的重连监督器、app-boot 的拒绝策略都在 DSH 里。上面是跨帖串联、一条定性建议和一个未验证的临时办法。

利益相关：我维护 pi2dsh（Pi 生态兼容层），它也能跑一套 Pi 生态的 MCP 运行时。这条不推销："SDK 写入路径抛 EPIPE 时会不会被当成断连处理"这个具体分支，我一次没测过——按我们自己的规矩，没测过就不能说绕得开。你完全可能换过去踩到同一个洞。