0.2.2-rc.1 已包含 Host 侧 process.exit() 修复（代码级确认）；0.2.1-rc.5 → 0.2.2-rc.1 仍会被桌面端 10s 判定拒绝

[LeonisK]

摘要

0.2.1-rc.5（Windows x64）在应用内升级到 0.2.2-rc.1 时仍然提示：

未能安全停止任务，更新尚未安装，请稍后重试。
desktop update: Host did not complete graceful task teardown (exit null, signal SIGTERM, shutdown acknowledged true, graceful deadline exceeded true)

现象与 #9963 / #10204 / #11032 / #11187 相同，本贴不重复描述现象，只补充两点新信息（已查重）：

1. 0.2.2-rc.1 的发布包已经包含 Host 侧修复：把 pending 目录里的 0.2.2-rc.1 NSIS 安装包解开、提取其中的 app.asar 后与 0.2.1-rc.5 逐文件 diff，dsh-desktop-host/lib/index.js 的 stop() 在发送 shutdown-complete + process.disconnect() 之后新增了 process.exit()；0.2.1-rc.5 的同一函数没有这一行（见下方代码）。也就是说，0.2.2-rc.1 的发布产物中已经带上了这类修复。
2. 桌面端的判定逻辑没有变：lib/main.js 的 stop(requireGraceful) 仍是“等 10 秒 → SIGTERM → exitCode 必须为 0”的写法，与 0.2.1-rc.5 一致。所以 0.2.1-rc.5 → 0.2.2-rc.1 这次升级仍然会失败（属于预期；先手动安装 0.2.2-rc.1 即可绕开）。但如果将来再出现“Host 已 ack 但进程未在 10 秒内退出”的情况，同一提示仍会复现。

环境

项	值
App	@deepseek-ai/dsh-desktop 0.2.1-rc.5
Electron / runtime	Electron 44.7.0 / Node 24.21.0
目标版本	0.2.2-rc.1（nightly；安装包已下载，SHA512 与 update-info.json 一致、Authenticode Valid）
系统	Windows 11 25H2 x64，zh-CN
安装方式	per-user（isAdminRightsRequired: false）
profile	desktop，加载了 10+ 个第三方宿主插件

观测

• 同日出现两次同型失败（上午一次、中午一次）；两次失败时都没有正在运行的 agent turn / bash job（可从会话事件日志确认：所有 turn 已闭合、所有 job 已 settled），因此可以排除“任务没停干净”。
• 失败后 Host 被重建、应用继续可用；安装器从未启动，安装目录保持 0.2.1-rc.5，pending 包完整（SHA512/签名均校验通过）。
• 桌面端崩溃日志（source: main, phase: startup, "dsh desktop host stopped"）只是失败后恢复 Host 的过程记录，不是 OS 级崩溃。

代码级证据（0.2.1-rc.5 vs 0.2.2-rc.1）

0.2.1-rc.5，dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js 的 stop()：

const stop = () => stopping ??= (async () => {
  await (await application.catch(() => void 0))?.shutdown.shutdown(0);
  await send({ type: "shutdown-complete" });
  if (process.connected) process.disconnect();
  // 没有 process.exit()：只能等事件循环自然排空
})();

0.2.2-rc.1 的同一个函数：

const stop = () => stopping ??= (async () => {
  ...
  const running = await application.catch(() => void 0);
  await running?.shutdown.shutdown(0);
  await send({ type: "shutdown-complete" });
  if (process.connected) process.disconnect();
  if (running !== void 0) process.exit();   // 新增：ack 之后强制退出
})();

另外，dsh/node_modules/@deepseek-ai/dsh/lib/profile-boot-*.js 的 createProcessShutdown 在 0.2.1-rc.5 与 0.2.2-rc.1 中一致：成功路径只是 process.exitCode = 0 + 清除 5 秒强制退出定时器，本身不调用 process.exit()。所以 ack（= teardown 完成）之后没有任何退出兜底。

据此，错误元组的唯一解释是：ack=true 说明 teardown 已完成，但进程没有退出；10 秒后桌面端 child.kill("SIGTERM")（Windows 上是 TerminateProcess，Node 子进程记账为 exit null, signal SIGTERM），而 stop(true) 的验收条件 !graceful || exitCode !== 0 || !shutdownCompleted 必然失败。不是“停机太慢”，也不是“任务没停”。

残留 handle 的触发面（本机实测）

• 通过 Host 内置 inspector 只读查看当前 Host 进程：持有 1 个常驻子进程（第三方隧道插件拉起的 cloudflared）、约 90 个 FSEventWrap 文件监视器、约 10 个 ref 定时器、多个 TCP socket（含长连接）、1 个 ref MessagePort。
• 未逐一确证是哪一项在失败时阻止了退出（旧 Host 已被 SIGTERM 强杀，事后无法枚举其 handle；相关子进程记录也在重启时被覆盖）。但这恰好说明：依赖“所有插件资源都被完整回收”并不可靠，Host 侧在 ack 后强制退出才是通用修复（0.2.2-rc.1 的做法）。

建议

1. 用户侧：0.2.1-rc.5 上不要反复点“安装并重启”（每次都会以同一错误失败并重建 Host）；退出应用后手动运行 pending 里已校验的 0.2.2-rc.1 安装包即可，升级后该路径不再复现。
2. 桌面端防御性加固（0.2.2 未改，建议后续版本考虑）：
   • stop(requireGraceful) 以 shutdownCompleted（ack）作为 teardown 完成的主判据；进程是否干净退出只记录诊断，不再硬失败；
   • exitPromise 同时竞速 exit 事件（当前只监听 close，若有孙进程继承 stdout 管道会把“已退出”误判为“未退出”）；
   • 默认落盘 update journal / updater 日志（现场默认没有日志，只能靠代码静态分析推断）。
3. Host 侧：process.exit() 之后未关闭的子进程会短暂成为孤儿；隧道插件已有“启动时回收 orphan”的机制，建议要么通用化，要么至少在日志里记录被遗留的子进程。

参考（同问题已有记录，供维护者合并）

#9963（根因主贴，8 条确认）· #10204 · #11032（master 修复未包含在发布包）· #11187（macOS）· #11274 · #8198 · #10901

---

本贴基于对 0.2.2-rc.1 安装包的静态分析（逐文件 diff）与本机实测，未修改安装目录、未运行安装器；为保护隐私未包含用户名/机器名等信息。

[meihuaanying]

Small correction to the conclusion "先手动安装 0.2.2-rc.1 即可绕开" for the other update failure mode: it does not cover the desktop update: task inspection timed out path.

I extracted app.asar from both shipped NSIS payloads (0.2.1-rc.5 and 0.2.2-rc.1) and compared:

• Your finding is confirmed: dsh-desktop-host/lib/index.js stop() gained if (running !== void 0) process.exit(); after shutdown-complete + process.disconnect() in 0.2.2-rc.1 — absent in 0.2.1-rc.5.
• But the other failing step did not change at all: installDesktopUpdateTaskControl is byte-identical between the two versions (1284 chars, old === new), including the unbounded await Promise.all(pendingRequests) drain, and the caller's budget in lib/main.js is still 1e4.

Ordering matters here: in 0.2.2-rc.1's main.js the drain failure is thrown by updateTasks("lock") at :20561, while backend.stop() — the code your process.exit() fix repairs — only runs at :20570. So on a machine where the admission lock times out, the graceful-teardown fix is never reached, and 0.2.1-rc.5 → 0.2.2-rc.1 still ends in 安装更新失败 for that class of users.

Full evidence and a timestamped Windows run of the manual-install workaround: #12361