[Bug] Desktop in-app update leaves resources\runtime empty → Host fatal on next launch (0.2.1-rc.5, no junctions involved)

[isnimi-xyz]

Summary

Every in-app update of the Windows desktop app leaves <install-dir>\resources\runtime as an empty directory. The next launch dies immediately with "DeepSeek Harness is unavailable", and the only recovery is to re-run the same-version installer from the updater cache by hand.

This is the fourth field report of the same failure (#10861, #11513, #11659, #11517). What is new here: it reproduces on a machine with zero reparse points anywhere under the install directory, and no resources\app directory at all. So the junction path described in #11659 cannot be the necessary condition.

Environment

OS	Windows x64
App	@deepseek-ai/dsh-desktop 0.2.1-rc.2 → 0.2.1-rc.5 (nightly channel)
Electron	44.7.0
Host Node	24.21.0
Update path	in-app update, then automatic restart

Symptom

Dialog: "DeepSeek Harness is unavailable — The application could not start or stopped unexpectedly."

Crash report (source: host, phase: startup):

DesktopHostFatalError: ENOENT: no such file or directory,
  open '<install-dir>\resources\runtime\office-skills\office\SKILL.md'
    at ChildProcess.<anonymous> (resources/app.asar/lib/main.js:3831:49)

--- host diagnostic ---
Error: ENOENT: no such file or directory,
  open '<install-dir>\resources\runtime\office-skills\office\SKILL.md'
    at readFileSync (node:fs:483:20)
    at resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-skill-office/lib/index.js:64:38
    at Array.map (<anonymous>)
    at new apply (.../dsh-skill-office/lib/index.js:61:33)
    at Fiber.execute (.../cordis/lib/index.js:1068:24)
    at async main (.../dsh-desktop-host/lib/index.js:331:2)

dsh-skill-office registers the bundled Office skills by reading each SKILL.md from assetRoot. The Host supplies that root as dirname(primaryRuntime) + "/office-skills" (see the desktop-office plugin in dsh-desktop-host/lib/index.js), i.e. resources\runtime\office-skills. There is no fallback and no preflight check, so an empty directory is a fatal startup error rather than a degraded one.

Observed state

resources\runtime exists, but Get-ChildItem returns 0 entries.

It should contain the full runtime payload:

runtime/
  primary-runtime/     dependencies/{node,python,pnpm}, runtime.json
  office-skills/       office, office-docx, office-pptx, office-xlsx,
                       office-render, office-recalculate, office-export-pdf
  bin/
  cli/

resources\app.asar.unpacked still contains its normal dsh directory, and the app files themselves were replaced correctly — only runtime is empty.

Timeline on this install

1. 0.2.1-rc.2 — in-app update → runtime empty → fatal.
2. Manual reinstall from the cached same-version installer → payload restored, app starts and runs normally for days.
3. 0.2.1-rc.5 — in-app update → runtime empty again → fatal.

The installer payload is therefore intact; only the update path fails to deploy it. Same conclusion as #11513.

Why the junction explanation does not fit here

Enumerating the whole install tree for reparse points returns nothing:

Get-ChildItem '<install-dir>' -Force -Recurse |
  Where-Object { $_.Attributes -band [IO.FileAttributes]::ReparsePoint }
# -> no results

resources\app does not exist. The only child of resources\app.asar.unpacked is a regular dsh directory.

So #11659's five-line repro is a valid way to trigger the damage, but junction following is not required — something in the --updated / /S path empties the directory on an ordinary install as well. My best guess matches #11513: the update replaces resources\runtime while the Host child process still holds handles inside it (notably primary-runtime\dependencies\node\bin\node.exe), the replace silently fails, and the failure is reported as success.

Impact

• After every in-app update the app is unusable until the user manually runs a ~290 MB installer.
• The dialog only offers Exit and Restart; Restart loops the same fatal error.
• The crash log is not reachable from the UI, so most users will not find the cause.
• The updater cache is deleted once a new update lands, so a user who updates twice before noticing has no matching installer left.

Suggested fixes, in order of value

1. Verify the payload after install — check that resources\runtime\office-skills and primary-runtime\dependencies\node actually exist (or re-check runtime.json's payloadDigest) and fail the update loudly instead of restarting into a broken install.
2. Make the --updated path re-extract resources\runtime even when the directory already exists. "Directory present" must not be treated as "payload present".
3. Stop the Host child and wait for its node.exe handles to close before replacing resources\runtime.
4. Fail gracefully at startup — if the runtime payload is missing or empty, show an actionable message ("update incomplete, reinstall from …") instead of a fatal ENOENT behind a modal that hides the log.

Workaround

Quit the app completely, then run the same-version installer from the updater cache manually. It performs a full install and restores the runtime.

---

中文摘要

Windows 桌面版每次应用内升级后，resources\runtime 都会变成空目录，下次启动 Host 直接 fatal（读不到 office-skills\office\SKILL.md），只能手动重跑同版本安装包恢复。

与已有几篇报告相比，这篇补充的关键事实是：本机安装目录内没有任何 junction / 重解析点，也不存在 resources\app 目录，因此 #11659 的 junction 路径不是必要条件；安装包本身是完整的（手动重装即可恢复），问题出在 --updated 静默升级路径上。建议升级完成后校验 runtime 载荷是否真的落地，而不是仅以"目录存在"判定成功。