【桌面端·自动更新】「未能安全停止任务，更新尚未安装」：退出闸门要求 Host 10 秒内自然退出，而 Host 从不强制退出 —— 有插件常驻子进程时必然拒装（rc.2 / rc.3 均复现）

[kkwings]

EN abstract — The desktop updater refuses to install a downloaded and verified update, because the shell requires the Host process to exit on its own within 10 s after the shutdown IPC (exitsWithin(exited, 1e4)). The Host stop() awaits shutdown(0), sends shutdown-complete (the "acknowledged" flag in the dialog) and disconnects — it never calls process.exit(), so it depends entirely on the Node event loop draining. Any live handle at that moment (e.g. a long-lived child process spawned by a plugin) keeps it alive; the shell then SIGTERMs it and refuses the install with DesktopHostUncleanExitError. autoInstallOnAppQuit = false, no fallback, and by default no log is written. Reproduced on 0.2.1-rc.2, still present in 0.2.1-rc.3 (identical code).

现象

更新包已下载并校验通过，点「安装并重启」后弹窗：

未能安全停止任务，更新尚未安装，请稍后重试。

展开「查看技术详情」：

desktop update: Host did not complete graceful task teardown (exit null, signal SIGTERM, shutdown acknowledged true, graceful deadline exceeded true)

结果：更新不安装，应用窗口也不再回来（用户感知为「包下好了但没自动重启」）。反复点击 100% 复现；跨版本两次尝试（rc.2 → rc.3）均如此。

定位（0.2.1-rc.3，app.asar 内行号；rc.2 相应行号 -1）

退出闸门 lib/main.js:3911-3927：

const graceful = await exitsWithin(exited, 1e4);   // :3920 只给 10 秒，要求进程「自己」退出
if (!graceful) child.kill("SIGTERM");              // :3921
// ...
if (requireGraceful && (!graceful || child.exitCode !== 0 || !this.shutdownCompleted))  // :3927
  throw new DesktopHostUncleanExitError("desktop update: Host did not complete graceful task teardown ...");

弹窗四个字段与代码逐一对应：exit null ← 被信号终止、无退出码；signal SIGTERM ← 10 秒超时后外壳发出的 SIGTERM；shutdown acknowledged true ← Host 已回 shutdown-complete；graceful deadline exceeded true ← !graceful。即：Host 明明确认了关机（ack），却因为没有在 10 秒内自行退出而被判为「不干净」。

Host 侧 @deepseek-ai/dsh-desktop-host/lib/index.js:264-268：

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()（唯一与退出码相关的是致命路径的 process.exitCode = 1，:368），也搜不到 spawn( / child_process / .kill( / unref(。也就是说：Host 做完应用层清理后完全依赖事件循环排空来结束进程，而它自己不会主动结束任何被插件 spawn 的子进程。

失败时刻的进程树（实测）：

DeepSeek Harness.exe (Electron 主进程)
└─ dsh-desktop-host (node)
   ├─ node_modules/luma-mcp/build/index.js   ← dsh-free-vision@1.0.8 的依赖，Host 启动约 3 秒后常驻
   ├─ dsh-subprocess-local runner ×2 → dsh-ptc-runtime-node
   └─ powershell.exe

因果说明（诚实标注）：「常驻子进程持有 handle 导致事件循环不排空」是对现象的合理假设——我没有抓到退出瞬间的 process._getActiveHandles() 列表（默认不写 journal，见下），无法直接证伪或证实。但以下两条是源码事实：① Host 从不 process.exit()，退出取决于事件循环；② 闸门要求 10 秒内自然退出。两者组合足以解释 100% 复现。

结构性错位：预检看「任务」，闸门看「进程」

更新前的预检 dsh-desktop-host/lib/index.js:101：

function hasDesktopActiveTasks(liveAgents, jobs) {
  return liveAgents.some((agent) => agent.status === "running" || agent.inbox.nextTurn.length > 0 || agent.inbox.nextStep.length > 0)
    || [void 0, ...liveAgents].some((agent) => jobs.list(agent?.id).some((job) => job.status === "running" || job.status === "stopping"));
}

它只枚举 running agent / inbox / running|stopping job，完全不涉及 OS 级句柄或插件 spawn 的子进程——而闸门拒绝安装的原因恰恰是后者。UI 文案同向印证（lib/preload-app.cjs、preload-welcome.cjs）：updateActiveTasksDetail: "更新将停止进行中的任务并重启应用，是否继续？"。于是：能被预检放行、又能拖住事件循环的东西（插件 spawn 的常驻子进程），正好落在预检与闸门之间的空档里。

复现步骤（稳定）

1. 用一个会 spawn 常驻子进程的插件 profile（本例 dsh-free-vision → luma-mcp），启动 DSH，确认该常驻子进程出现。
2. 打开任意会话，触发更新到有新版可用的 feed（自动检查或手动「检查更新」）。
3. 点「安装并重启」（注意：不会出现「仍有进行中的任务」确认框）。
4. 观察：10 秒后弹窗「未能安全停止任务…」+ 上述技术详情字符串；应用窗口不再回来；安装包仍留在 pending 目录。
5. 重复第 3 步：100% 复现。（最终只能手动运行 pending 目录里的安装包完成更新。）

影响与建议

• 影响：只要更新时刻 Host 仍有活 handle（插件常驻子进程 / socket / timer），自动更新必然失败；叠加 lib/main.js:7808 autoInstallOnAppQuit = false（连「退出时补装」的兜底都没有）、默认不写 journal（DSH_DESKTOP_UPDATE_JOURNAL_DIR 未设置即不落盘），用户与支持侧都只能看到「请稍后重试」。
• 建议：
  1. Host 在收到 shutdown-complete 之后显式 process.exit(0)（或至少在所有插件卸载完成后强制退出）；
  2. 闸门失败时给出可操作出口：列出挡着的进程/句柄 + 提供「仍然安装」选项 + 可配置超时；
  3. 预检补上进程级检查（插件 spawn 的子进程、活跃 handle），与闸门判据对齐；
  4. 失败默认写 journal（或至少写一行到 logs/），便于用户上报；
  5. autoInstallOnAppQuit 打开作为兜底。
• 顺带一问：DSH_DESKTOP_* 全部环境变量里没有任何放宽 10 秒窗口的开关，1e4 是硬编码字面量，这是有意为之吗？

环境摘要（脱敏）

• Windows 11 Pro x64；安装目录 <安装目录>
• 更新前 0.2.1-rc.2（resources 全部为 2026-10-17 17:20 构建）→ 更新后 0.2.1-rc.3（dshBuildCommit = be72761ee1a6736ebcdf4f3739363b083ae53c98，dshBuildDirty = false）
• 更新源 app-update.yml：provider=generic，url=https://download.deepseek.com/dsh-desk/feeds/win-x64/，channel=nightly
• 两版关键代码逐行相同：lib/main.js 均为 13198 行 / 516716 字节