[Bug] 桌面版更新被永久拒绝：Host 已确认 shutdown-complete，却因 10 秒内未退出被 SIGTERM（0.2.0-rc.2 → 0.2.1-rc.2）

[kopfkinoqwq]

DSH 桌面版更新失败：Host 已完成任务清理却无法在 10 秒内退出，导致更新被永久拒绝

面向 triage 的摘要（English）：The desktop updater refuses to install a downloaded release because
the Host child exits only after the 10 s graceful window (killed by SIGTERM), even though the Host
did acknowledge shutdown-complete. Because stop(requireGraceful) requires
graceful && exitCode === 0 && shutdownCompleted together, an acknowledged-but-lingering Host blocks
every in-app update on affected machines. Workaround today is running the staged installer manually.

---

1. 环境

项	值
产品	DeepSeek Harness 桌面版（Electron）
系统	Microsoft Windows 11 家庭版 中文版，10.0.26300（x64）
安装目录	D:\ai tools\deepseek harness（per-user 安装，注册表 HKCU\...\Uninstall）
更新通道	nightly，feed https://download.deepseek.com/dsh-desk/feeds/win-x64/
出问题的版本	0.2.0-rc.2 → 目标 0.2.1-rc.2（该缺陷在 0.2.1-rc.2 上同样存在，见 §6）
复现率	100%，同一台机器每次点「安装并重启 / 停止任务并更新」都失败

2. 现象

在应用内点击更新 → 下载成功（pending\deepseek-harness-0.2.1-rc.2-win-x64.exe 已落盘）→ 确认安装后
弹出错误对话框：

• 标题：DeepSeek Harness 更新
• 正文：未能安全停止任务，更新尚未安装，请稍后重试。
• 「查看技术详情」：

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

安装器从未被执行，版本停留在 0.2.0-rc.2；外壳随后走恢复分支把 Host 重新拉起，工作区仍可用。
重试任意次数结果完全相同。

3. 复现步骤

1. 启动 DeepSeek Harness 0.2.0-rc.2（nightly 通道）。
2. 等待版本检查发现 0.2.1-rc.2 并完成下载（状态变为 ready）。
3. 点击「安装并重启」；若有活动任务则点击「停止任务并更新」。
4. 观察：10 秒后 Host 被 SIGTERM 结束，更新中止，弹出上述错误；应用回到旧版本并重启 Host。

不依赖任何特定任务内容：空会话、无后台作业时同样复现。

4. 证据

4.1 进程与网络

失败发生期间，Host 子进程（DeepSeek Harness.exe --expose-internals ... dsh-desktop-host）常驻持有：

127.0.0.1:19387        Listen        ← GUI 端口
127.0.0.1:54101/54102  Listen
127.0.0.1:63068        Listen
0.0.0.0:51993/51994    Bound → 对 443 的 Established（TLS keep-alive）
127.0.0.1:19387        Established ×3（渲染进程的 WS/HTTP 连接）

同样的形态在升级到 0.2.1-rc.2 后依旧（新端口 64905、Listen + 多条 Established），说明这不是
某个版本特有的残留进程，而是 Host 进程的常态。

4.2 已下载安装包的可信性（排除下载/校验问题）

文件   : %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.1-rc.2-win-x64.exe
大小   : 289,385,456 bytes
SHA-512: 39POl5osl9PKMqrPXQA52dh/bCV0Z02vOV9cTjOJDHE6gsJwp5bv7lfgB3mVWAKspX7a/w1iTi+8Listdhq45g==
         （与同目录 update-info.json 记录完全一致）
签名   : Authenticode 有效，CN="Hangzhou DeepSeek Artificial Intelligence Co., Ltd."

即：不是包有问题，也不是落盘失败，纯粹是安装前的停机闸门拒绝了它。

5. 代码路径与根因分析

5.1 判定逻辑（外壳侧，lib/types/host-process.js）

async stop(requireGraceful = false) {
  ...
  if (child.connected) child.send({ type: "shutdown" }, ...);
  const exited = this.exitPromise ?? Promise.resolve();
  const graceful = await exitsWithin(exited, 1e4);   // 10 s，硬编码
  if (!graceful) child.kill("SIGTERM");
  if (!await exitsWithin(exited, 5e3)) { child.kill("SIGKILL"); ... }
  ...
  if (requireGraceful && (!graceful || child.exitCode !== 0 || !this.shutdownCompleted))
    throw new DesktopHostUncleanExitError(
      `desktop update: Host did not complete graceful task teardown (exit ${...}, signal ${...},
       shutdown acknowledged ${...}, graceful deadline exceeded ${...})`);
}

更新确认流程（confirmDesktopUpdateInstall）在 backend.stop() 之前置 requireCleanStop = true，
随后把该错误包装成 DesktopUpdatePreparationError("stop-failed", updateStopFailed)，安装被放弃。

5.2 Host 侧的停机顺序（dsh-desktop-host）

const stop = () => stopping ??= (async () => {
  await (await application.catch(() => void 0))?.shutdown.shutdown(0);  // 卸载插件 / 清理任务
  await send({ type: "shutdown-complete" });                            // ← 通知外壳“我清理完了”
  if (process.connected) process.disconnect();
})();

5.3 关键矛盾

报错里同时出现：

• shutdown acknowledged true → Host 已经跑完 shutdown.shutdown(0) 并回传 shutdown-complete；
• graceful deadline exceeded true → 但进程本体在 10 秒内没有退出。

两者并存说明：任务清理是成功的，卡住的是清理之后的事件循环——stop() 结束后只做了
process.disconnect()，没有 process.exit()，也没有显式关闭监听套接字 / keep-alive 连接。
只要有任一 handle 存活（§4.1 里的监听端口或 TLS 长连接），Node 进程就不会自然退出，于是必然吃满
10 秒、必然收到 SIGTERM、必然被判 unclean。

5.4 因此设计上的判定过严

requireGraceful 用的是合取：graceful && exitCode === 0 && shutdownCompleted。
但 shutdownCompleted === true 本身就意味着状态已落盘、插件已卸载——此时进程是否立刻消失，
与数据安全无关。把「清理完成但进程残留句柄」与「清理没完成」同等对待，会让受影响机器永远无法通过
UI 更新；而绕过它的唯一办法（杀掉应用后手跑安装包）反而比自动路径风险更高，这与该闸门的安全意图相反。

6. 建议修复（任选其一即可解除阻塞，建议 1 + 2 都做）

1. Host：清理完成后强制退出。 在 shutdown-complete 之后 setImmediate(() => process.exit(0))；
   或在 application.shutdown 里显式 server.close() + 关闭所有连接、http.Agent.destroy()、
   unref 定时器，保证事件循环可清空。
2. 外壳：区分「清理失败」与「清理完成后进程残留」。

   if (requireGraceful && !this.shutdownCompleted) throw new DesktopHostUncleanExitError(...);
   if (requireGraceful && this.shutdownCompleted && !graceful)
     console.warn("desktop update: Host acked teardown but lingered; proceeding");

   即在 shutdownCompleted 为 true 时允许更新继续（必要时先 SIGTERM 再继续），仅在真正
   清理未确认 时才拒绝安装。
3. 诊断能力： SIGTERM 之前通过一条 debug control 消息让 Host 回报 process._getActiveHandles()
   的类型统计，这样同类问题的报告能直接定位残留句柄，而不是只能看到 signal SIGTERM。

7. 当前变通做法

退出应用后直接执行已下载的安装包（pending\deepseek-harness-0.2.1-rc.2-win-x64.exe，/S 静默亦可），
注册表版本随即变为 0.2.1-rc.2。已验证可行，但需要用户手动操作，且不是官方支持的更新路径。

---

[Explorer-cc]

遇到相同的问题：

[Ender-Kylin]

遇到相同的问题
desktop update: Host did not complete graceful task teardown (exit null, signal SIGTERM, shutdown acknowledged true, graceful deadline exceeded true)

[sweven-tears]

同样是这个错误：
desktop update: Host did not complete graceful task teardown (exit null, signal SIGTERM, shutdown acknowledged true, graceful deadline exceeded true)

[YIBOWAY]

补充一个 macOS Apple Silicon 的同类实例，以及“取消定时任务后更新成功”的线索。

环境与现象

• DeepSeek Harness 官方桌面版，macOS 27.0.1 / arm64。
• 发生于 2026-10-24，应用内从 0.2.1-rc.2 更新到 0.2.1-rc.3。
• 原会话存在一个通过原生 schedule_create 创建的每小时重复任务（every_seconds: 3600）。
• 更新包已经下载完；本地计算的 SHA-512 与 pending/update-info.json 一致。
• 点击安装并重启后弹出“未能安全停止任务，更新尚未安装，请稍后重试”，技术详情为：

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

与楼主的 signal SIGTERM 有区别：本例最终显示 exit 0, signal null，但同样是 shutdown acknowledged true 和 graceful deadline exceeded true。

实际观察到的恢复过程

1. 定时任务仍存在时，应用内更新失败，随后外壳重新拉起旧版本 Host，应用恢复可用，安装版本仍为 0.2.1-rc.2。
2. 我取消了该定时任务。
3. 再次执行重启更新，成功完成；本机应用版本随后已核实为 0.2.1-rc.3。

这是一次真实的“取消任务前失败 / 取消任务后成功”的观察，尚未重新创建同一任务反复验证。也没有记录精确到失败瞬间的调度状态，因此暂不能确定是未来待触发的计时器、正在投递的任务，还是调度与退出之间的竞争造成了延迟。

可供排查的方向

检查过出问题的 0.2.1-rc.2 安装包：桌面 stop(requireGraceful) 等待上限为 10 秒，且等待的是子进程的 close；Host 在 shutdown.shutdown(0) 返回后发送 shutdown-complete。这一组事实尚不足以确定具体残留资源。

建议优先检查 schedule 的等待/投递在应用退出时是否被取消和回收，以及更新准备阶段是否可能继续触发调度。可以补充“有待触发的重复任务，但没有前台生成”及“恰好到期投递”两个退出/更新测试，并记录 shutdown-complete、进程 exit、close 各自的时间。

预期是更新过程能够暂停并回收调度中的活动资源，保留持久化任务供重启后恢复；用户不应需要取消自己的定时任务才能安装更新。

补充边界：这个 profile 有第三方插件，包括带本地修改的 dsh-pet；未做纯净 profile 对照，所以这里报告的是定时任务相关的可操作线索，不把任何单一组件写成已确认根因，也不建议直接绕过更新的清理检查。

English summary: On macOS arm64, the 0.2.1-rc.2 → rc.3 in-app update failed with exit 0, signal null, shutdown acknowledged true, graceful deadline exceeded true. An hourly native scheduled reminder existed. After cancelling that reminder, the update succeeded and the installed version was verified as 0.2.1-rc.3. This is a single before/after observation, not a proven scheduler-only root cause; the exact timer/delivery state at failure was not captured. Please investigate schedule cancellation/disposal and update-shutdown races.