0.2.1-rc.3 仍会在 Host 完成收尾确认后拒绝应用内更新（master 修复 6252a29a 未包含在发布包）

[sagawz]

在 Windows 上，桌面端应用内更新会在 Host 已回报 shutdown-complete、但进程没有在 10 秒优雅期内退出时拒绝安装，界面提示：

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

环境：0.2.1-rc.2 → 0.2.1-rc.3（nightly，Windows x64，Electron 44.7.0，Node 24.21.0，zh-CN）。更新包已下载且 SHA-512 与 update-info.json 一致、签名有效，可排除下载/损坏问题。rc.3 构建提交 be72761ee1a6736ebcdf4f3739363b083ae53c98。

经过：壳向 Host 发送 shutdown 并等待 10 秒（apps/desktop/src/host-process.ts 的 DesktopHostProcess.stop()）→ Host 完成收尾并发送 shutdown-complete（所以 shutdown acknowledged true）→ 但某个插件遗留句柄使进程继续存活；apps/cli/src/process-shutdown.ts 中 5 秒强制退出定时器已在 dispose() 完成时被 completeOnce() 清掉，之后没有任何机制强制退出 → 壳的 10 秒到期，升级为 SIGTERM（Windows 上是硬终止：exit null / signal SIGTERM）→ 抛出 DesktopHostUncleanExitError 并拒绝安装，随后恢复旧版本 Host。

判断：master 的 apps/desktop-host/src/index.ts 已在 shutdown 路径末尾加 if (running !== undefined) process.exit()（commit 6252a29，2026-10-18，配测试 23fb3ea）。而 0.2.1-rc.2/rc.3 打包的 dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js 仍是修复前版本（disconnect 后没有 process.exit()）。

想确认：① 该修复是否进入下一个 nightly 桌面构建？② 若 0.2.1-rc.x 仍要发版，能否把这个一行修复回移植？否则从 rc.2/rc.3 升级的用户都可能需要手动结束进程并直接运行暂存安装包。

绕过方式：结束所有 DeepSeek Harness 进程（注意：窗口 × 只是隐藏到托盘，不会退出），再直接运行 %LOCALAPPDATA%@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.1-rc.3-win-x64.exe，可正常安装并自动重启。会话记录在 ~/.dsh/sessions，不会丢失。

[PerryLink]

这条修复确实不在 rc.3 里，你判断对了。

我按 tag 核了一遍：dsh-v0.2.1-rc.3 指向 1f81c047，而 6252a29a（fix(desktop-host): exit after acknowledged teardown）只是 master 的祖先，git merge-base --is-ancestor 6252a29a 1f81c047 是否定的。所以发布包里不可能带它，这跟你看到的 "graceful deadline exceeded" 完全对得上。

在下一个 rc 之前，可以试两个绕法：

一是更新前先把插件都停掉再触发更新，减少遗留句柄，让 Host 在 10 秒内退出；二是确认更新包已经下载校验完后，手动结束 host 进程再点更新——安装器不会重下，校验值你已经比对过。

另外你提到的 rc.3 构建提交 be72761e 和 tag 指向的 1f81c047 不是同一个，这本身说明桌面端的发布构建和 git tag 不是一一对应。如果要向官方报，这一点值得单独列出，因为它会让"某修复在不在这个版本里"变得无法从 tag 判断。

[Acfufu]

补一条硬确认:该修复到 0.2.1-rc.5 仍未随包分发。

• tag 比对: 6252a29a → dsh-v0.2.1-rc.4 与 → dsh-v0.2.1-rc.5 均为 diverged(非 ancestor);本机 rc.5 发包 dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js 的 stop() 在 process.disconnect()(lib/index.js:266)后仍无 process.exit()
• macOS arm64(rc.3→rc.5)同样复现,最终形态是 exit 0, signal null:profile-boot 注册的 process.on("SIGTERM") → interrupt(0) 救场退出,SIGTERM 被处理所以退出码干净;核心不变——shutdown acknowledged true 而 graceful deadline exceeded,升级被拒,重试才成功
• 对照组(逐秒 lsof 采样一次成功升级的 teardown):webserver LISTEN :* 与全部 TCP 连接在最后 2 秒内清空后,进程立即自行退出——事件循环能否在 10 秒窗口内排空直接决定成败
• 诉求同楼主:请把 6252a29a(连同测试)赶进下一个桌面端构建;若能顺带把优雅判定基点移到 shutdown-complete 之后,慢排空造成的误拒也会一并消失

[PerryLink]

复核了，你的 tag 结论对，代码也支持。

• 祖先关系：git merge-base --is-ancestor 6252a29a dsh-v0.2.1-rc.5 为否，rc.3/rc.4/rc.5 都是否，master 为是。
• 代码层面能直接看出差别：master 的 apps/desktop-host/src/index.ts 在 stop() 里 :67 disconnect 之后还有 :70 的 if (running !== undefined) process.exit()，上面的注释（:68-69）写的就是"插件留下的句柄会把宿主拖过优雅期限"。rc.5 的同一文件只有 :57 的 disconnect，没有这一行。

所以 rc.5 里宿主只能等事件循环自己排空，排不空就超时 → shutdown acknowledged true 而 graceful deadline exceeded → 更新被拒，重试才碰上刚好排空的那次。macOS 那次干净的 exit 0, signal null 是 profile-boot 的 SIGTERM handler 救的场，不是修复生效——你已经核到这一层了。

如果需要把报告说得更硬，建议直接贴这两行对照（master :70 vs rc.5 缺），比"未包含该 commit"更难被反驳。

[Acfufu]

按建议补上同一文件的源码对照,比"未包含该 commit"更好核。

master(apps/desktop-host/src/index.ts,修复已入):

64:    const running = await application.catch(() => undefined)
65:    await running?.shutdown.shutdown(0)
66:    await send({ type: 'shutdown-complete' })
67:    if (process.connected) process.disconnect()
68:    // A handle a disposed plugin left open would otherwise keep the Host alive past the shell's graceful
69:    // deadline; a startup failure keeps its own diagnostic exit.
70:    if (running !== undefined) process.exit()

dsh-v0.2.1-rc.5 tag 同文件(rc.3/rc.4 相同):

52:   const stop = (): Promise<void> => stopping ??= (async () => {
53:     // Startup failure is reported by main; shutdown only owns a tree that booted.
54:     const running = await application.catch(() => undefined)
55:     await running?.shutdown.shutdown(0)
56:    await send({ type: 'shutdown-complete' })
57:    if (process.connected) process.disconnect()
58:   })()   // ← disconnect 之后直接结束;无 line 68-70 等价物

即 rc.5 发包在 ack + disconnect 后只能指望事件循环自然排空,任一插件遗留的引用句柄都会拖过壳层 10 秒宽限——与我们两侧(macOS/Windows 用户)的观测全部吻合。

诉求:请随下一个桌面端构建带上 master 的 stop() 终态 process.exit()(即 6252a29a,连同测试);如方便,发布说明里注明含该修复,便于下游直接验证。等待期间的临时绕法(手动结束 host 进程后点击更新,或手动运行 staged 安装包)目前有效,但希望尽快让内置升级自己转起来。