Desktop update always fails: Host bounded-shutdown (5s) force-exits before sending shutdown-complete

[wzn16]

Environment

• macOS 15, Apple Silicon (arm64)
• DeepSeek Harness desktop 0.1.7-rc.2 → 0.2.0-rc.1 (nightly channel)
• Profile with ~22 third-party plugin bundles + several MCP servers

Steps & symptom

Click "Update" (in-app). The dialog consistently fails with:

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

Reproduces 100% of the time, including after a full app restart. The pending package was already downloaded
(~/Library/Caches/@deepseek-aidsh-desktop-updater/pending/), so I installed it manually by unzipping it over
/Applications/DeepSeek Harness.app — that worked, confirming the package itself is fine and only the teardown
handshake fails.

Root cause (read from the 0.1.7-rc.2 app.asar)

• Shell side, DesktopHostProcess.stop(requireGraceful = true) refuses to install unless: child exited and
  exit code is 0 and a shutdown-complete IPC ack was received while stopping.
• Host side, createProcessShutdown (lib/types/process-shutdown.js) uses PROCESS_SHUTDOWN_TIMEOUT_MS = 5000.
  On dispose timeout or dispose rejection it calls process.exit(0) immediately. The host's
  send({ type: "shutdown-complete" }) sits after await application.shutdown.shutdown(0) in its stop(),
  so on a forced exit the ack is never sent.
• Therefore any machine whose plugin tree takes more than 5 s to dispose (large profiles: many plugins, MCP
  servers, long-lived sessions) or whose dispose rejects will fail every in-app update, deterministically.
  exit 0, signal null, deadline false, ack false is exactly that signature.

Suggested fixes (any one would do)

1. In createProcessShutdown, send shutdown-complete (with a forced: true flag) right before forceExit(code).
2. Or relax the shell check: within the 10 s graceful window, accept exitCode === 0 even without the ack when the
   pre-update updateTasks("lock") round reported no active tasks.
3. Or make the 5 s teardown bound configurable / scale it with the number of loaded bundles.

[1renren2]

Cross-link: I filed the Windows counterpart as #8284 — same subsystem, but a different layer and a different (silent) symptom.

On Windows (desktop 0.2.0-rc.1 → 0.2.0-rc.2, nightly) the graceful-teardown gate evidently passes: the NSIS installer really does launch and extracts a complete payload into <INSTDIR>.new-{GUID} (10,916 items / 1,015 MB, including a freshly generated Uninstall DeepSeek Harness.exe stamped 0.2.0-rc.2). But the directory swap never completes, because DeepSeek Harness.exe and resources\app.asar are still held open by the running app — both return "being used by another process" while the app is up. Nothing is surfaced anywhere; the only visible symptom is that the update badge returns on every launch.

The same cached installer, with the same --updated /S flags, succeeded in 24 seconds once every DeepSeek Harness.exe process was stopped and those two files were proven unlocked.

So the shutdown-complete ack looks necessary but not sufficient for a replaceable install: what the installer needs is for the main process to have released the executable and app.asar before it starts replacing them. Worth keeping in mind for whichever fix lands here. Full evidence and three suggested fixes in #8284.