Windows desktop: GUI update always fails — Host never exits (koffi keeps the event loop alive)

[FENGMX3C]

Summary

On Windows, clicking Check for Updates → Update in the desktop app always fails with:

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

The Host does complete its graceful shutdown and acknowledges it (shutdown acknowledged true), but the Host process never exits, so the shell SIGTERMs it after the 10 s grace window and refuses the handoff. Manual installers work fine; only the in-app update path is affected.

Root cause: the Host process loads koffi (native FFI, pulled in by @deepseek-ai/dsh-fs-local/win32 and the Windows console-signal installer). koffi creates two referenced libuv pipe handles at load time for its cross-thread callback channel and never releases them. desktop-host never calls process.exit() after shutdown-complete, so the Host relies on the event loop draining — which it never does once koffi is loaded.

Environment

• Version: 0.2.1-rc.2 (also reproduced on 0.2.1-rc.1; the failed update was rc.2 → rc.1)
• Channel: nightly
• OS: Windows (x64), desktop app (DeepSeek Harness.exe)
• User data under $DSH_HOME (moved to another drive via directory junctions, unrelated to the bug — reproduced with default layout too)

Reproduction

1. Launch the desktop app with a downloaded update pending.
2. Click Update.
3. Observe the error above. The Host process stays alive for the full 10 s, then is killed by SIGTERM.

The same thing happens on any normal quit (silently): the window closes but the process tree survives ~10–15 s before being force-killed.

Evidence

1. koffi alone pins a Node process forever

# baseline: ~55 ms
node -e "console.log('done')"

# koffi native module only: process never exits (killed after 8 s)
node -e "require('<app>/resources/app.asar.unpacked/dsh/node_modules/@koromix/koffi-win32-x64/win32_x64/koffi.node'); console.log('loaded')"

# control: another native module from the same runtime exits in ~105 ms
node -e "require('.../node-addon-require-builtin-win32-x64-msvc/.../win32-x64-msvc-napi-v9.node'); console.log('loaded')"

# control: Electron itself in node mode exits in ~335 ms
$env:ELECTRON_RUN_AS_NODE=1; "<app>/DeepSeek Harness.exe" -e "setTimeout(()=>{},300)"

# control: signal listeners do NOT block exit (57–100 ms)
node -e "process.on('SIGINT',()=>{}); process.on('SIGBREAK',()=>{}); console.log('done')"

2. koffi adds two referenced pipes

process.report.getReport().libuv, before/after requiring koffi.node:

BEFORE  ["async(unref)","async(unref)","timer(idle)(unref)","check(unref)",
         "idle(idle)","prepare(unref)","check(unref)","async(unref)","loop(idle)(unref)"]

AFTER   [ ...same... , "pipe(idle)","pipe(idle)", "loop(idle)(unref)" ]
                        ^ two additional pipes, no (unref) => referenced

They persist indefinitely:

t+0ms    pipes = []
t+1s     pipes = ["pipe/(idle)/ref", "pipe/(idle)/ref"]
t+3s     pipes = ["pipe/(idle)/ref", "pipe/(idle)/ref"]   # never released

3. Inside the real Host: teardown finishes, the process still doesn't exit

A temporary diagnostic plugin dumped process._getActiveHandles() / process.getActiveResourcesInfo() from its ctx.effect dispose callback (unref'd sampling timer) during a real quit:

moment	visible handles
dispose starts	23 — {Pipe:1, Socket:13, Server:1, FSWatcher:5, ChildProcess:3} (3 MCP servers, 5 file watchers, the web server)
+500 ms	2 — everything above released
+1000 … +9500 ms	still 2, process alive
+10 s	killed by SIGTERM

So all plugin-owned resources are released within 500 ms; the residual liveness comes from non-JS libuv handles created by koffi.

4. koffi exposes no way to release it

Grepping the JS layer of the installed koffi package for unload|dispose|shutdown|unref|finalize returns nothing. The pipes are created in the N-API layer and are not exposed.

Code pointers

• app.asar/lib/main.js — DesktopHost.stop(requireGraceful):

  child.send({ type: 'shutdown' });
  const graceful = await exitsWithin(exited, 1e4);
  if (!graceful) child.kill('SIGTERM');
  ...
  if (requireGraceful && (!graceful || child.exitCode !== 0 || !this.shutdownCompleted))
    throw new DesktopHostUncleanExitError(...)

• app.asar/dsh/node_modules/@deepseek-ai/dsh-desktop-host/lib/index.js — stop() never exits explicitly:

  const stop = () => stopping ??= (async () => {
    await (await application.catch(() => void 0))?.shutdown.shutdown(0);
    await send({ type: 'shutdown-complete' });
    if (process.connected) process.disconnect();
  })();

• koffi consumers: @deepseek-ai/dsh-fs-local/win32 (Win32 ACL/DACL helpers) and the CLI’s installWindowsCliSignals() (SetConsoleCtrlHandler; its comment even says “The registration lasts until process exit”).

Suggested fix (any one is enough)

1. Preferred: in dsh-desktop-host stop(), call process.exit(0) right after send({ type: 'shutdown-complete' }) (after the IPC flush). Everything has already been torn down at that point, so there is nothing to flush afterwards.
2. Or release koffi's wake-up pipes on shutdown (uv_unref / napi_finalize), or expose an explicit koffi.unref()/koffi.unload().
3. Or relax requireGraceful: a Host that acknowledged shutdown and whose teardown released all resources should not be rejected because of a native handle it cannot release.
4. Meanwhile, please allow the in-app updater to fall back to the downloaded installer when the handoff fails, instead of leaving the user stuck (the installer itself works perfectly).

User-side workaround (for other users hitting this)

A tiny profile plugin can force the exit after teardown settles:

ctx.effect(() => () => {
  let stable = 0;
  const poll = setInterval(() => {
    const busy = process.getActiveResourcesInfo()
      .filter(t => !['PipeWrap','Timeout','FSReqCallback','FSReqPromise','WriteWrap','ShutdownWrap'].includes(t));
    if (busy.length === 0) stable++; else stable = 0;
    if (stable >= 4) process.exit(0);       // ~1 s of settled teardown
  }, 250);
  poll.unref();
  setTimeout(() => process.exit(0), 6000).unref();   // hard cap, well inside the 10 s window
}, 'clean-exit');

With this plugin, quits go from “hang 10 s then SIGTERM” to “exit in ~1 s, exitCode 0”, and in-app updates succeed.

---

(中文摘要)

Windows 桌面端点「更新」必定失败并报 Host did not complete graceful task teardown。原因是宿主进程加载了 koffi（原生 FFI，由 dsh-fs-local/win32 与控制台信号安装器引入），它在初始化时创建两条 referenced 的 libuv pipe 用于跨线程回调唤醒，且从不释放；而 desktop-host 的 stop() 在发完 shutdown-complete 后没有调用 process.exit()，只依赖事件循环排空，于是进程永远不退，10 秒后被 SIGTERM，更新器判定交接不干净而拒绝安装。

实测：所有插件资源在 teardown 后 500ms 内全部释放；单测 require koffi.node 后进程 8 秒仍不退出，而同样环境下其他原生模块与 Electron-as-node 都在百毫秒级正常退出。建议在 stop() 里补一行 process.exit(0)。

[longxing-alt]

Independent measurements on 0.2.0-rc.2 → 0.2.1-rc.2 (Windows 11 x64), plus a second leak path, plus a fix that is correct no matter which handle is guilty.

1. What I could confirm

Same symptom, 100% reproducible, and it is definitely not task-related (all agents/jobs idle):

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

2. koffi at load time is not sufficient here

On this build, loading koffi and actually calling through it exits immediately, under both plain Node and ELECTRON_RUN_AS_NODE:

control        node -e console.log              -> 97 ms, code 0
koffi require  node -e require(koffi.node)       -> 112 ms, code 0
koffi require  ELECTRON_RUN_AS_NODE              -> 138 ms, code 0
koffi load+call (GetCurrentProcessId)            -> 215 ms, code 0

So the module load alone does not create referenced pipes on this combination (Electron 44 / Node 22 / the @koromix/koffi-win32-x64 shipped with 0.2.0-rc.2). If the pipes come from koffi's cross-thread callback channel, the minimal repro needs a registered callback (or a call into the real consumers: @deepseek-ai/dsh-fs-local/win32, installWindowsCliSignals()) — require(koffi.node) alone may not be enough to prove it. Worth tightening, because the conclusion ("host cannot drain") is right while the mechanism may be one of several.

3. A second, independent way to pin the loop: MCP stdio children

I booted the real desktop profile in a child process (profile copy, DSH_HOME pointed at it, --port 19389), called shutdown.shutdown(0) and dumped handles:

shutdown resolved in 130ms, exitCode=0
[immediately-after-shutdown] children=43164:0   // ChildProcess handle still registered
                                               // but the PID is already gone (ESRCH)

Mechanism: StdioClientTransport.close() (in @modelcontextprotocol/client) resolves on the child 'close' event, and Node only emits 'close' when the process has ended and every stdio stream is closed. MCP servers that fork a helper inheriting those pipes never produce 'close':

• figwright spawns a follower ("became FOLLOWER (leader @ 127.0.0.1:3055)"),
• tempad spawns a shared hub.mjs (\\.\pipe\tempad-mcp),
• obs (no helper) releases cleanly.

With tempad disabled the survivor simply becomes figwright, i.e. the handle follows whichever server forks a helper — it is not one specific server.

In my controlled boot that handle cleared about a second later, so it is not sufficient on its own — but when the helper is long-lived (a shared hub that outlives its parent, as on my machine) the handle never goes away, and it composes with whatever koffi leaves behind.

4. What my controlled boot does not reproduce

A fresh profile boot + shutdown() exits naturally with code 0, about 950 ms after dispose, no force needed:

shutdown resolved in 130ms, exitCode=0
EXITING naturally with code 0 after 952ms

So the 10 s hang needs something the real workspace has and a bare boot does not (a live session, a terminal, a background job, a long-lived MCP helper, koffi's callback pipes once a consumer registers one). I am not claiming to have named the single guilty handle — the point below is that the fix should not depend on naming it.

5. Suggested fix: bound the exit, do not rely on the loop draining

The invariant the update handshake actually needs is "dispose finished and the process is gone". Right now only the first half is bounded:

// @deepseek-ai/dsh/profile-boot — createProcessShutdown
timeout = setTimeout(() => { forceExitOnce(code); }, timeoutMs);   // 5 s
pending = Promise.resolve().then(dispose).then(() => {
  if (forceAfterDispose) forceExitOnce(code);
  else completeOnce(code);   // sets process.exitCode AND clears the watchdog
}, () => { forceExitOnce(code); });

Proposed (keeps healthy quits byte-identical, makes a stuck handle cost 5 s instead of forever):

    pending = Promise.resolve().then(dispose).then(() => {
      if (forceAfterDispose) forceExitOnce(code);
-     else completeOnce(code);
+     else {
+       completeOnce(code);
+       // dispose success does not mean the loop drained: a native handle or a
+       // grandchild holding inherited stdio can keep it alive forever.
+       // Re-arm unref'd so a healthy process is never held open by the guard,
+       // and log what survived when it fires.
+       timeout = setTimeout(() => {
+         process.stderr.write(`dsh: shutdown left active resources: ${JSON.stringify(process.getActiveResourcesInfo?.() ?? [])}\n`);
+         forceExitOnce(code);
+       }, timeoutMs);
+       timeout.unref();
+     }
    }, () => { forceExitOnce(code); });

And in dsh-desktop-host, stop waiting for a natural exit after the IPC flush (your option 1, which I agree is right):

  const stop = () => stopping ??= (async () => {
    await (await application.catch(() => void 0))?.shutdown.shutdown(0);
    await send({ type: "shutdown-complete" });
    if (process.connected) process.disconnect();
+   setTimeout(() => process.exit(0), 1_500).unref();
  })();

And the root-cause half for the MCP path, in @deepseek-ai/dsh-mcp-client: after the transport closes, destroy our stdio ends and unref() the handle once the direct child is gone, so a surviving helper cannot decide the Host's lifetime. (Do not kill the process tree here: tempad's hub is a cross-client singleton, killing it would break other consumers.)

6. Why this also covers #8198

#8198 is the same missing boundary from the other side: there the 5 s watchdog fires before dispose finishes (shutdown acknowledged false); here it is disarmed after dispose and nothing bounds the exit (shutdown acknowledged true + 10 s). One rule fixes both: keep an unref'd guard armed until the process is actually gone, and let dispose have its own (larger) budget.

Happy to open a PR against packages/profile-boot + apps/desktop + packages/mcp/mcp-client if a maintainer confirms the direction. I also have the probe harness (boots the desktop profile in a child, calls shutdown(), dumps _getActiveHandles()/getActiveResourcesInfo()) if it is useful as a regression test.

[wwbyh123]

Confirming this on 0.1.5-rc.1 -> 0.2.1-rc.2, Windows 10, desktop profile.

Environment

• DSH 0.1.5-rc.1 upgrading to 0.2.1-rc.2 (win-x64)

• GPU: RTX 2080 Ti (driver 617.42), display 2560x1440 @150% scaling

• 4 update attempts, all failed identically. The in-app updater downloads the installer
  successfully (pending/deepseek-harness-0.2.1-rc.2-win-x64.exe, 276 MB, signature valid),
  then reports:

  "Host did not complete graceful task teardown
  (exit null, signal SIGTERM, shutdown acknowledged true, graceful deadline exceeded true)"

5 hypotheses were tested and all disproven:

1. a bare setInterval keeping the loop alive (removed, unref'ed) - still failed
2. an in-flight agent turn - still failed with no active turn
3. a 30s awaited archive step - reduced to 5s, still failed
4. a disabled custom plugin - still failed with the plugin disabled
5. oversized session - still failed on a fresh session

Workaround that worked: run the already-downloaded installer manually
(%LOCALAPPDATA%@deepseek-aidsh-desktop-updater\pending\deepseek-harness-0.2.1-rc.2-win-x64.exe,
isAdminRightsRequired=false). After that the app started on 0.2.1-rc.2 normally.

This matches the koffi theory: no JS-level suspect reproduced it, and shutdown was
"acknowledged true" yet never completed - consistent with a native handle keeping the
loop alive. Sharing in case it helps confirm the root cause.

(Evidence gathered with an AI assistant assisting log collection; report posted by the user.)

[Code-89757]

Confirming the same failure on 0.2.0-rc.2 → 0.2.1-rc.2 (Windows x64, nightly),
i.e. the 0.2.0 host is affected too, not only 0.2.1:

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

Environment

• Desktop 0.2.0-rc.2 (Electron 44.0.0, runtime Node 24.21.0)
• Windows 11 Home China, build 26300.9711, x64
• Channel: nightly (feed https://download.deepseek.com/dsh-desk/feeds/win-x64/)
• Installer: deepseek-harness-0.2.1-rc.2-win-x64.exe, 289,385,456 bytes,
  downloaded to %LOCALAPPDATA%@deepseek-aidsh-desktop-updater\pending;
  SHA-512 matches update-info.json
• Time: 2026-10-19 ~10:52 local (UTC+8)

What happened

1. The update downloaded completely, then the install/restart step started.
2. The shell asked the host to shut down; the host acknowledged (shutdown-complete)
   but the process did not exit within the 10 s window.
3. The shell sent SIGTERM and refused the handoff (exit null, code != 0),
   then restored the old host; the app is still on 0.2.0-rc.2.

Additional observation (may help narrow the mechanism)

In the 0.2.0-rc.2 app.asar, the only code reference to koffi is
installWindowsCliSignals() in the CLI entry (dynamic import("koffi")).
The desktop host path (@deepseek-ai/dsh-desktop-host → runProfile + web host)
does not import koffi. So on 0.2.0, "koffi loaded at host startup" does not seem
to be the mechanism. Worth checking whether 0.2.1 added a koffi consumer on the
host path.

Workaround

Manual install from the pending installer: [worked / not tried yet — update after trying]

Happy to collect process.getActiveResourcesInfo() / handle dumps on the next
attempt if that helps.