[0.2.2-rc.1][Windows] In-app update still deadlocks at the pendingRequests drain — installDesktopUpdateTaskControl is byte-identical to 0.2.1-rc.5

[meihuaanying]

TL;DR

In-app update 0.2.1-rc.5 → 0.2.2-rc.1 on Windows x64 still fails with the same dialog:

安装更新失败，请稍后重试。
desktop update: task inspection timed out

The download itself is fine. Two byte-level findings from diffing the two shipped app.asar files:

1. installDesktopUpdateTaskControl is byte-identical between 0.2.1-rc.5 and 0.2.2-rc.1 (1284 chars, old === new). The await Promise.all(pendingRequests) drain — with no exemption for long-lived responses — is unchanged.
2. In lib/main.js, updateTasks() changed only by an added 4th argument (a log label). The budget is still 1e4 (10000 ms).

Consequence: the process.exit() teardown fix that 0.2.2-rc.1 ships (discussed in #12237) cannot help here. This failure happens before backend.stop() is ever reached — it is thrown by updateTasks("lock"), at lib/main.js:20561, while backend.stop() only runs at :20570.

Environment

Item	Value
App	@deepseek-ai/dsh-desktop 0.2.1-rc.5 → 0.2.2-rc.1
Channel	nightly, provider: generic, https://download.deepseek.com/dsh-desk/feeds/win-x64/
OS	Windows 11 家庭版 (Home) zh-CN, 10.0.26200, Build 26200, x64
Install	per-user NSIS (isAdminRightsRequired: false), D:\program\DSH, no admin rights
Payload	%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.1-win-x64.exe, 293,425,336 B
Payload integrity	SHA-512 swcK0J6ofGkaAWLRpOes2ca7CWO8vuM5Vp0FRnQ/DG3q+Z+OhvsgLz3hIiSYpRUETY+fEz+Ww86fNa0jiVIifw== = feed nightly.yml exactly; Authenticode Valid, signer CN=Hangzhou DeepSeek Artificial Intelligence Co., Ltd.
Runtime	node 24.21.0 / pnpm 11.28.5 (resources/runtime/versions.json)

So: not a network problem, not a hash problem, not a disk problem, not a signature problem. The payload was already complete on disk before the retry; I re-verified SHA-512 against the feed by hand.

Where it fails (0.2.2-rc.1 line numbers)

resources/app.asar → lib/main.js:

:20542  const active = await host.updateTasks("inspect");          // 1e4 budget
:20561  const stillActive = await host.updateTasks("lock");       // 1e4 budget  ← dies here
:20564  await platformView.closeAndWait();
:20570  await Promise.all([backend.stop(), stopOperationReports()]);
:20576  shellInstallerOwnsQuit = true;

resources/app.asar → dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js:

:271  function installDesktopUpdateTaskControl(ctx) {
:272    let locked = false; let lockGeneration = 0; let stopped = false;
...
:280    const pendingRequests = new Set();
:281    ctx.on("connection/request", async (_request, response, next) => {
:282      if (locked) { response.writeHead(503); response.end(); return; }
:283      const finished = Promise.withResolvers();
:284      pendingRequests.add(finished.promise);
:285      try { await next(); } finally { pendingRequests.delete(finished.promise); finished.resolve(); }
:286    });
...
:303      if (action === "lock") {
:304        locked = true;
:305        const generation = ++lockGeneration;
:306        await Promise.all(pendingRequests);              // ← unbounded drain, no exemption
:307        if (stopped) throw new Error("desktop update: Host is stopping");
:308        if (generation !== lockGeneration) throw new Error("desktop update: admission lock was superseded");
:309      }
:310      return hasDesktopActiveTasks(agents.list(), jobs);

Every request accepted by the connection waterfall is registered in pendingRequests and only settles in the finally. Any accepted response that stays open for the lifetime of the GUI keeps Promise.all(pendingRequests) pending forever, and the shell gives up at 10 s.

Note that in 0.2.1-rc.5 the same function lives at :108, with the drain at :143 — and the extracted function bodies compare equal, so no part of this control was touched by the 0.2.2-rc.1 release.

Same function, both versions, 0.2.2-rc.1 on the left:

old len 1284   new len 1284   identical: true

updateTasks() diff, 0.2.1-rc.5 vs 0.2.2-rc.1:

  async updateTasks(action) {
    const response = await this.control({
      type: "update-tasks",
      action
-   }, 1e4, "desktop update: task inspection timed out");
+   }, 1e4, "desktop update: task inspection timed out", "desktop update");

What I could and could not confirm

• Measured: while the desktop app is simply idle with its window open, the Host keeps 7 ESTABLISHED TCP connections to its loopback GUI port (2924 in 0.2.2-rc.1; 12985 in 0.2.1-rc.5). They belong to the shell main process and do not close.
• Confirmed by code: browser-side event streams use new WebSocket(...) (dsh-api-gateway/lib/client.browser.js:342, dsh-client-connection/lib/client.browser.js:1348), so the main /api event channel is an HTTP upgrade and does not pass through connection/request. Plain /api RPC calls are POST with requestBodyMode: "buffered" and therefore do settle.
• Not confirmed: which exact accepted response is the one that never settles. Candidates are plugin-registered routes going through dsh-host-webserver (MCP SSE endpoints, tunnel/proxy plugins, streaming "operation report" channels) or the shell's own long-poll route. This is precisely the part that is undiagnosable after the fact: a timeout writes no log, and inspect and lock share both the deadline and the message, so task inspection timed out cannot be told apart from drain stuck.
• dsh-host-webserver/lib/index.js:204-206 already detects text/event-stream — but only inside the gzip filter. That predicate is not reused by the drain, so an SSE response that is perfectly well known to the webserver still counts as a request that must settle.

Reproduce

1. Install 0.2.1-rc.5 (per-user), launch it, leave the window open, let it download 0.2.2-rc.1.
2. Make sure no agent turn / job is running (hasDesktopActiveTasks must be false, otherwise the confirmation dialog asks to stop tasks first — that is a different, successful path).
3. Click "安装并重启 / Install and restart".
4. Wait 10 s → 安装更新失败，请稍后重试。 with technical detail desktop update: task inspection timed out. The installer never starts; resources/app.asar still reports 0.2.1-rc.5; the Host is restarted and the app stays usable.

Repeating the click fails identically, because the condition is a property of a live GUI, not a transient state.

Workaround (verified on this machine)

Quit the app completely, then run the already-downloaded, already-verified installer with exactly the arguments NsisUpdater.doInstall() uses:

"%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.2-rc.1-win-x64.exe" --updated /S --force-run

Result on this machine: installer ran 66 s, exit code 0, --force-run relaunched the app itself, app.asar package.json → 0.2.2-rc.1, registry DisplayName/DisplayVersion → 0.2.2-rc.1, no profile or session loss.

The catch is that this works only because the process tree is gone; it is not something a user can do from inside the app, and the failure dialog offers no pointer to it.

Suggested fixes

In rough order of value per line changed:

1. Exempt long-lived responses from the drain. Either reuse the existing text/event-stream predicate, or let a route declare itself ambient so it is never added to pendingRequests. Without this, the guarantee "no request in flight when the installer starts" is unachievable for any GUI whose whole purpose is a live stream.
2. Give the drain its own bounded budget and answer instead of timing out. Promise.race the drain against e.g. 2 s; on expiry return { active: true, reason: "drain-timeout" } plus the pending count, so the shell renders a true diagnosis rather than inspection timed out.
3. Split the two deadlines and the two messages. inspect (must be fast) and lock (drain) currently share 1e4 and one string; that is why reports like this one and [Bug] Desktop auto-updater fails with "desktop update: task inspection timed out" due to live renderer connection deadlock in installDesktopUpdateTaskControl #10003/[BUG][Desktop 0.2.1-rc.3] 安装更新反复失败：desktop update: task inspection timed out —— 任务排空 10 秒死线过短 #11991/[Bug] macOS 桌面内更新失败："desktop update: task inspection timed out"（10s 硬超时 / 无日志 / inspect 与 lock 不可区分） #11828 all end up with the same sentence and no way to separate "Host busy" from "drain stuck".
4. Log every update-tasks outcome to disk by default: action, elapsed ms, admitted count, pending count, settle results. There is currently no update journal unless an env var was set at launch, so every field report has to be reconstructed from static analysis.
5. Offer the fallback in the error dialog. The installer binary is already on disk and correctly signed; a "run the downloaded installer" button (or at least printing the exact command and path) unblocks every affected user without waiting for a release.
6. Optionally, have the shell close/signal its own renderer before acquiring the lock, so the shell's ambient streams are not part of the drain at all.

Relation to existing reports

Duplicate-checked before posting; this is intended as a delta, not a re-report:

• [Bug] Desktop auto-updater fails with "desktop update: task inspection timed out" due to live renderer connection deadlock in installDesktopUpdateTaskControl #10003 — first precise identification of the await Promise.all(pendingRequests) deadlock (macOS 0.2.1-rc.1→rc.2), plus a Windows confirmation in the comment. I am reusing their analysis; what is new here is that 0.2.2-rc.1 still contains it verbatim.
• [BUG][Desktop 0.2.1-rc.3] 安装更新反复失败：desktop update: task inspection timed out —— 任务排空 10 秒死线过短 #11991 — 0.2.1-rc.3, "10 秒死线过短".
• [Bug] macOS 桌面内更新失败："desktop update: task inspection timed out"（10s 硬超时 / 无日志 / inspect 与 lock 不可区分） #11828 — macOS, "10s 硬超时 / 无日志 / inspect 与 lock 不可区分".
• 0.2.2-rc.1 已包含 Host 侧 process.exit() 修复（代码级确认）；0.2.1-rc.5 → 0.2.2-rc.1 仍会被桌面端 10s 判定拒绝 #12237 — graceful-teardown timeout (Host did not complete graceful task teardown), a different failing step. Its conclusion "install 0.2.2-rc.1 manually and this path stops reproducing" holds for that path; it does not cover this one, because the lock step fails first and 0.2.2-rc.1 did not change it. Worth stating explicitly so nobody reads "0.2.2-rc.1 fixes the updater" and skips this.
• dsh自动更新会失败 #12345 / 升级报错 #9960 — Windows users reporting "update only works right after a reboot, before DSH has been started". Same observable, different mechanism (file locks / ERROR_SHARING_VIOLATION); the workaround happens to coincide.

New information contributed by this report:

1. 0.2.2-rc.1 does not contain a fix — proven by function-level equality of installDesktopUpdateTaskControl between the two shipped asar files, not by observation.
2. 0.2.2-rc.1's process.exit() teardown fix is irrelevant to this path, because lock fails before backend.stop() is called.
3. A complete, timestamped Windows end-to-end run of the out-of-band workaround (66 s install, --force-run self-relaunch, three version sources agreeing afterwards).

No usernames, machine names, session contents or tokens are included. If a maintainer wants the extracted app.asar fragments or the exact byte offsets used for the comparison, I can attach them.