[Bug] Desktop auto-updater fails with "desktop update: task inspection timed out" due to live renderer connection deadlock in installDesktopUpdateTaskControl

[Notoonex]

Environment

• App: DeepSeek Harness Desktop (macOS arm64)
• Version: 0.2.1-rc.1 attempting update to 0.2.1-rc.2
• OS: macOS Sequoia 15.x

Problem Description

When clicking "Install & Restart" (or "Relaunch to Update") on macOS Desktop, the update modal always fails with:
Error: desktop update: task inspection timed out

Even when there are no active agent tasks, no subagents, and no background jobs running, the update inspection consistently times out after 10,000ms.

Root Cause Analysis (Code Inspection)

In installDesktopUpdateTaskControl:

const pendingRequests = new Set();
ctx.on("connection/request", async (_request, response, next) => {
    if (locked) {
        response.writeHead(503);
        response.end();
        return;
    }
    const finished = Promise.withResolvers();
    pendingRequests.add(finished.promise);
    try {
        await next();
    } finally {
        pendingRequests.delete(finished.promise);
        finished.resolve();
    }
});

return async (action) => {
    if (action === "lock") {
        locked = true;
        const generation = ++lockGeneration;
        await Promise.all(pendingRequests); // <-- Deadlock point
    }
    return hasDesktopActiveTasks(agents.list(), jobs);
};

And in the caller (DesktopUpdateCoordinator.beforeRestart / updateTasks):

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

The Deadlock Mechanism:

1. All /api requests pass through connection/request waterfall and are added to pendingRequests.
2. The Desktop Electron renderer window maintains persistent/long-polling HTTP/SSE/WebSocket streams to the internal host to maintain UI state, logging, and metrics.
3. When updateTasks("lock") is called, it awaits Promise.all(pendingRequests) to drain all admitted requests.
4. Because the renderer window remains open, these connections never self-terminate, so pendingRequests is never cleared.
5. The 10-second timeout in this.control(...) expires, rejecting with desktop update: task inspection timed out.

Suggested Fix

1. Exclude persistent/ambient GUI streams (e.g., SSE event streams, long polling) from pendingRequests draining, OR
2. Have the desktop updater explicitly close/signal the renderer to drop ambient streams before acquiring the admission lock, OR
3. Add a bounded drain timeout for Promise.all(pendingRequests) that force-aborts ambient connections rather than letting the whole update inspection fail.

[Wuyunonjiji]

Windows x64 confirmation of the same failure (0.2.1-rc.3 → 0.2.1-rc.5), plus a workaround that worked.

Not a download or signature problem. The payload was already downloaded and is intact:

• %LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.1-rc.5-win-x64.exe exists and its SHA-512 matches the one in update-info.json
• Authenticode: Valid, signer CN="Hangzhou DeepSeek Artificial Intelligence Co., Ltd." (GlobalSign EV)

So the 10 s deadline is genuinely the only failure point.

Two clarifications that may narrow the root cause:

1. Both calls share the same 10 000 ms deadline and the same message: lib/main.js:3858 updateTasks() is called with action inspect (:12336) and later lock (:12357). The reported error therefore cannot tell "Host busy" from "drain stuck". Splitting the deadlines/messages would make the report self-diagnosing.

2. On Windows the Web UI's live event stream is a WebSocket (dsh-api-gateway registers an upgrade route; dsh-client-connection openConnectionWebSocket), so it does not sit in pendingRequests. On my machine there were 10 established connections to the Host port and the update still timed out, which is consistent with the pin being either (a) a plain HTTP request whose handler never settles (streaming/proxy response, e.g. a mirror plugin), or (b) an event-loop stall longer than 10 s — note the inspection itself is synchronous (hasDesktopActiveTasks, host index.js:101-103). A timeout currently leaves no log at all, so the two cannot be told apart after the fact.

Workaround (verified, per-user install, no admin rights needed): quit the app completely, then run the already-downloaded installer with the same arguments electron-updater itself uses (NsisUpdater.doInstall, NsisUpdater.js:107-113):

"%LOCALAPPDATA%\@deepseek-aidsh-desktop-updater\pending\deepseek-harness-<ver>-win-x64.exe" --updated /S --force-run

The registry DisplayName then flips to the new version and app.asar reports the new version; no profile or data loss.

Suggested fixes, in addition to bounding the drain:

• Promise.race the drain with its own budget and answer { active: true, reason: "drain-timeout" }, so the Host responds instead of the shell hitting its deadline
• exclude long-lived responses from the drain (reuse the existing text/event-stream detection at dsh-host-webserver/lib/index.js:204)
• log action / pending-request count / elapsed time on every update-tasks, and surface the pending count in the failure dialog
• offer a "run the downloaded installer" fallback in the error dialog — by itself that unblocks every affected user

[meihuaanying]

Cross-reference from a fresh Windows reproduction: 0.2.2-rc.1 still ships this bug unchanged.

I diffed the shipped app.asar of 0.2.1-rc.5 against 0.2.2-rc.1 (both extracted from their NSIS payloads):

• installDesktopUpdateTaskControl is byte-identical — 1284 chars in both, old === new. The await Promise.all(pendingRequests) drain at dsh-desktop-host/lib/index.js:306 (0.2.2-rc.1) / :143 (0.2.1-rc.5) has no exemption for long-lived responses, still.
• lib/main.js updateTasks() differs only by an added 4th argument (a log label); the budget is still 1e4.

So 0.2.2-rc.1's new process.exit() in the Host stop() (the fix discussed in #12237) does not help this path at all: the failure is thrown by updateTasks("lock") at main.js:20561, while backend.stop() only runs at :20570. Your "10 s deadline is genuinely the only failure point" reads exactly right for 0.2.2-rc.1 too.

I posted the full write-up with the 0.2.2-rc.1 evidence and a timestamped Windows end-to-end run of the --updated /S --force-run workaround here: #12361

Two notes that may be of interest to you specifically:

1. I also could not find the offending response. On this machine the shell keeps 7 ESTABLISHED connections to its loopback GUI port while merely idle, but the /api event channel is a WebSocket upgrade (dsh-api-gateway/lib/client.browser.js:342), so — as you said — it never enters pendingRequests. That leaves plugin-registered routes (MCP SSE, tunnel/proxy plugins) as the likely holder.
2. dsh-host-webserver/lib/index.js:204-206 already has the text/event-stream predicate, but only inside the gzip filter. That is the one-line hook a fix could reuse.