Windows 桌面端点「安装并重启」永久卡在「正在准备重启…」，安装器从未启动（0.2.1-rc.2 → rc.3）

[Mrsoso-1987]

桌面端（Windows）0.2.1-rc.2 → rc.3 升级：点「安装并重启」后永久卡在「正在准备重启…」，
应用不退出、不报错、安装器从未启动。等待 19 分钟无任何变化，只能杀掉进程。

摘要 / TL;DR

The update downloads fine (276 MB, SHA512 + Authenticode verified), but the pre-restart
handshake never completes:

• the app keeps running with the old version (0.2.1-rc.2), the toolbar shows “正在准备重启…” forever;
• no installer process is ever created, no NSIS temp dir, target files untouched;
• the DSH host child process is still alive, so backend.stop() was never reached;
• no error dialog, no timeout, no log.

Code-wise, DesktopUpdateCoordinator.install() sets phase: "installing" before awaiting
beforeRestart(). Every step inside beforeRestart() except one has a deadline; the only
unbounded await is platformView.closeAndWait() (Chromium closeAllConnections() /
clearStorageData() / webContents 'destroyed' event). That is where the flow is stuck.

环境 / Environment

App	DeepSeek Harness Desktop 0.2.1-rc.2 (app.asar!package.json, uninstall registry DisplayVersion)
Electron	44.7.0 (<install dir>/version)
OS	Windows 10 家庭中文版 22H2, 10.0.19045, x64
CPU / RAM	i7-7700HQ / 16 GB
Install dir	E:\DeepSeek Harness（内置 1 TB 机械硬盘，非 SSD）
Update channel	nightly, generic provider https://download.deepseek.com/dsh-desk/feeds/win-x64/
Target	0.2.1-rc.3 (289,415,960 bytes)
Security software	Windows Defender and McAfee both active (real-time scanning)

复现步骤 / Steps

1. 从 0.2.1-rc.2 启动桌面端，状态栏提示有新版本 0.2.1-rc.3。
2. 点「升级」，等待下载完成（进度条到 100%，随后「正在校验更新文件…」）。
3. 弹出确认框，点「安装并重启」。
4. 界面进入「正在准备重启…」，此后永久停留。

实际结果 / Actual

• 时间线（2026-10-25，本地时间）：
  • 16:18:45 应用启动（单实例 PID 24172；host child PID 22596 16:19:03）
  • 16:19:53 current.blockmap 写入；16:21:11 pending\deepseek-harness-0.2.1-rc.3-win-x64.exe
    (289,415,960 B)；16:21:17 pending\update-info.json
  • 16:21:47 默认 session 的 Network\Cookies 被写（点击后的遥测上报）
  • 之后 无任何 新文件、无进程变化
  • 17:00+（约 19 分钟后）仍在「正在准备重启…」：主窗口正常响应，PID 不变
• 安装器从未运行：无 deepseek-harness-0.2.1-rc.3-win-x64.exe 进程、%TEMP% 无 NSIS 解压目录、
  E:\DeepSeek Harness 内文件时间仍是 10/17 17:20、version 仍为 0.2.1-rc.2 对应内容。
• host child（PID 22596）仍存活并在正常服务 Web UI ⇒ backend.stop() 没有被执行到。
• 没有「更新失败」弹窗，也没有任何超时。
• 同一台机器在 10/18 也下载过一版安装包（updater cache 里 installer.exe，289,385,456 B），
  应用文件至今仍是 10/17 的 ⇒ 不是一次性偶发，可重复。

期望结果 / Expected

要么在合理时间内完成安装（应用退出 → 安装器运行 → 自动重启），要么在 N 秒后给出可见错误、
可重试、并落日志。绝不能无限期静默挂起。

代码定位 / Where it hangs

app.asar → lib/main.js

DesktopUpdateCoordinator.install(version)（约 L7875-7899）：

this.setState({ phase: "installing", version });     // UI 立刻显示「正在准备重启…」
...
if (!await this.beforeRestart()) return this.setState({ phase: "ready", version });
this.assertLive();
this.updater.quitAndInstall(true, true);             // 只有走到这里才会拉起安装器

beforeRestart()（约 L12329-12376）的每一步与其上限：

步骤	超时
commandManager.idle()	无（等原生命令对话框）
await workspaceRecovery / await startup	无（初始化尚未结束时会等）
host.updateTasks("inspect")	10 s（control(..., 1e4, ...)，L3861）
确认框 updateDialog.show()	等用户
track("desktop_upgrade_install_restart_click")	1 s（AbortSignal.timeout(1e3)）
host.updateTasks("lock")	10 s
platformView.closeAndWait()	无（L6950-6954）
backend.stop() → host.stop(true)	10 s 优雅 + 5 s SIGTERM + 5 s SIGKILL（L3919-3926）
quitAndInstall()	—

因为 host 进程仍然活着、且没有任何错误弹窗，能同时满足这两点的只可能是
platformView.closeAndWait() 这个唯一没有超时的 await：

// L6919-6942 close()
const destroyed = new Promise(resolve => { ... view.webContents.once("destroyed", resolve); ... });
browserSession.flushStorageData();
this.cleanStorage(browserSession, destroyed);

// L6950-6954
async closeAndWait() {
  this.close();
  const failures = (await Promise.all(this.storageCleanup.values()))...  // ← 无上限
}
// cleanStorage: await browserSession.closeAllConnections(); await clearStorageData(); await clearCache(); ...

closeAllConnections() / clearStorageData() / webContents 'destroyed' 都是 Chromium 侧调用，
在分区里存在 service worker、SSE/长连接或挂起的 IndexedDB 事务时都可能不返回；
storageCleanup 还是一个按 session 累积的 Map，一旦其中某个 promise 曾经挂住，后续每次
closeAndWait() 都会立刻挂住。

影响 / Impact

• 桌面端无法自升级：用户只能手动杀进程 + 手动跑安装包。
• 界面无进度、无取消、无失败提示；用户会反复点、反复等，或误以为磁盘/杀软很慢。
• 应用内更新日志默认不落盘（DesktopUpdateJournal 仅在 DSH_DESKTOP_UPDATE_JOURNAL_DIR
  存在时创建，L12045-12046），因此这类问题是“零证据”的，难以自助排查。

建议修复 / Suggested fixes

1. 给 closeAndWait() 加上限（最小改动，直接解决本 issue）：

   const cleanup = this.platformView.closeAndWait().catch(e => { /* 记日志 */ });
   await Promise.race([cleanup, delay(5000)]);   // 清理是 best-effort，不该阻塞安装

2. 给整个 beforeRestart() 加看门狗（例如 60 s），超时后：

   • 立刻 setState({ phase: "error", failedOperation: "install", message: "更新准备超时" })
     并在 UI 上给出「重试 / 查看日志 / 仍然安装」；
   • 或直接降级为「强制退出 + quitAndInstall()」，不要因为清理失败而放弃安装。

3. UI：「正在准备重启…」应显示当前子步骤（停止任务 / 关闭账户视图 / 重启安装器）并允许取消；
   超过 30 s 至少提示“仍在准备，可查看日志”。

4. 日志：DesktopUpdateJournal 在失败路径或 phase === "installing" 时默认落盘到
   %LOCALAPPDATA%\@deepseek-ai\dsh-desktop\logs\，并记录每个子步骤的耗时。

5. 别把安装绑死在清理上：安装器本身会等待进程退出（NSIS checkAppRunning），
   因此可以「先 spawn 安装器、再 best-effort 清理并退出」，把不可控的 Chromium 调用移出关键路径。

6. 次生问题：beforeRestart() 在 currentDialogWindow() === undefined 或
   updateDialog.show() 返回非 0 时直接 return false，状态回到 ready 而没有任何提示
   （L12350-12351、L7884-7887），用户会看到“点了没反应”。建议区分「用户取消」与「无法准备」，
   后者必须提示原因。

规避 / Workaround（给其他用户）

手动升级路径（我本机已验证可行）：

1. 完全退出 DSH（托盘退出 / 任务管理器结束所有 DeepSeek Harness.exe）。
2. 运行 updater 缓存里已下载好的安装包：
   %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-<version>-win-x64.exe
   （先在 pending\update-info.json 核对 SHA512）。
3. 静默安装参数：/S /D=<安装目录>（/D 必须最后且不能加引号）。

需要自升级自动化的话，可以用一个外置脚本完成「拉 feed → 校验 SHA512/签名 → 结束进程 →
/S /D= 安装 → 校验 exe 版本 → 启动」，绕开这段握手。

附：如何抓取本问题的证据

设环境变量 DSH_DESKTOP_UPDATE_JOURNAL_DIR=<一个可写目录> 后启动桌面端，再走一次升级，
会在该目录生成 <timestamp>-<uuid>.jsonl，逐条记录
started / download-requested / state:installing / install-confirmed / quit-requested 及时间戳。
如果最后一条停在 state:installing 且没有 install-confirmed，即可确认卡在 beforeRestart()。

关于本报告的脱敏 / Privacy

本报告由用户在其机器上自查后整理，已剔除：

• 用户名、机器名（COMPUTERNAME）、Windows 账户 SID、安装目录之外的用户目录路径；
• ~/.dsh 下的匿名用户 ID（.anonymous-user-id）、会话 ID、工作区路径、会话内容；
• Cookie、令牌、IP/MAC 地址、内网主机名、DNS 记录；
• 已下载安装包的本地完整路径（统一写成 %LOCALAPPDATA%\...）。

保留的仅为定位所需：应用/Electron 版本、Windows 版本与补丁号、CPU 型号与内存大小、
安装盘类型（机械盘）、磁盘上的时间戳、文件大小、以及公开更新源 URL。
其中 CPU/内存/磁盘类型是为了说明“安装本身可能慢”的量级，可自行删除而不影响结论。