Update install leaves the app running with a retired Runtime Host, and never applies the update

[MasamiYui]

What happened

Installing a Desktop update never completes. The app keeps running with its Runtime Host already retired, so every Host-backed IPC channel fails and the UI empties out: the Projects list renders "No project" and refreshing model connections reports a network error. The error is misleading — nothing is wrong with the network.

The update itself is never applied. /Applications/Maka.app stays on the previous version, so the next launch offers the same update and fails the same way. The only way out is to quit and relaunch manually.

This reproduces on every install attempt on this machine.

Expected: the app quits, Squirrel replaces the bundle, and the app relaunches on the new version.

How to reproduce

1. Run a packaged nightly build (observed on 0.2.0-dev.39.20260916).
2. Let the updater find a newer nightly, or trigger a check from Settings → About.
3. Click install once the update is downloaded and verified.
4. The window stays open. Within ~15s the Projects list shows "No project" and a "刷新模型连接失败 / 网络错误" toast appears.
5. The process never exits. ~/Library/Caches/com.maka.desktop.ShipIt/ShipIt_stderr.log shows ShipIt waiting for it.
6. Quit manually and relaunch. The app works again, but the bundle is still the old version.

Environment

• Maka version: 0.2.0-dev.39.20260916 (packaged, nightly channel)
• OS: macOS 25.6.0 (darwin, arm64)
• Surface: Desktop
• Electron 43.4.1 / Chrome 150.0.7871.224 / Node 24.18.1

Logs, screenshots, or additional context

ShipIt, showing it wait ten minutes for a process that never exits, then abort because the app came back (local time):

2026-09-20 10:43:28.878 ShipIt[23809] Detected this as an install request
2026-09-20 10:53:37.123 ShipIt[23809] Beginning installation
2026-09-20 10:54:01.154 ShipIt[23809] Aborting update attempt because there are 1 running instances of the target app
2026-09-20 10:54:01.154 ShipIt[23809] Installation cancelled: Error Domain=SQRLInstallerErrorDomain Code=-9 "App Still Running Error"

The same failure occurred on an earlier attempt that day (10:03:15 → 10:03:58), which is why it reads as always reproducible rather than a race.

Desktop diagnostic report from the same run (UTC, +8h offset from the log above). The Host exits cleanly at 10:43:23 local, and the first IPC failure lands exactly 15s later — DEFAULT_REPLACEMENT_WAIT_TIMEOUT_MS:

[2026-09-20T02:43:23.914Z] INFO [runtime-host] candidate exited cleanly { pid: 68872, code: 0, signal: null }
[2026-09-20T02:43:38.857Z] ERROR Error occurred in handler for 'skills:listInvocable': RuntimeHostHandlerUnavailableError
[2026-09-20T02:50:48.218Z] ERROR Error occurred in handler for 'projects:getSnapshot': RuntimeHostHandlerUnavailableError
[2026-09-20T02:50:48.200Z] ERROR Error occurred in handler for 'connections:getSnapshot': RuntimeHostHandlerUnavailableError

Runtime Host connections (1)
"local": reconnecting
Main process uptime: 2856s

Two details narrow it down:

• The report was captured at 02:51 UTC with uptime 2856s, i.e. the process started at 02:03 and never restarted. The window was still visible, so prepareToQuit() never reached its browserWindow().destroy().
• There is not a single [runtime-host] reconnecting: line after the Host exits. The reconnect lifecycle was quiesced by the retirement and never rescheduled, which is why the state stays reconnecting forever without producing an error.

Root cause

installUpdate retires the Host (quiesce() + candidateLaunchBarrier.pause()) before calling quitAndInstall, and that retirement only unwinds through the rollback stored in installHandoff. The quit that was supposed to follow never finishes, because prepareToQuit() and cleanup() are awaited without any upper bound. Once a stage stops settling, phase stays in preparing/cleaning and every later quit request is swallowed by if (phase !== 'running') return after the event was already prevented.

Squirrel's ShipIt is an independent process that only waits for the target to exit, so a quit that never finishes blocks the install indefinitely with nothing to read. The App Still Running Error at the end is a consequence, not the cause: by the time the user gives up and relaunches, ShipIt has finally started installing and finds the app running again.

[sunrioa]

Another occurrence, on a newer nightly. Two details here sharpen the diagnosis above.

Environment: 0.2.0-dev.44.20260920 (packaged, nightly), macOS 25.5.0 (darwin, arm64), Electron 43.4.1 / Chrome 150.0.7871.224 / Node 24.18.1.

Same signature. Desktop diagnostic report (UTC; local time is +08:00):

[2026-09-22T15:14:02.664Z] INFO [runtime-host] candidate exited cleanly { pid: 6985, code: 0, signal: null }
[2026-09-22T15:14:17.822Z] ERROR Error occurred in handler for 'client-plugins:snapshot': RuntimeHostHandlerUnavailableError
...
Runtime Host connections (1)
"local": reconnecting
Main process uptime: 116232s

The Host exits cleanly, the first IPC failure lands 15.2s later (DEFAULT_REPLACEMENT_WAIT_TIMEOUT_MS), and across the five minutes of failures that follow there is not a single [runtime-host] reconnecting: line — the quiesced lifecycle never reschedules, exactly as described. The toast differs only in which handler was asked first: here memory:getState ("刷新本地记忆状态失败 / 网络错误") rather than the connection refresh.

1. App Still Running Error is downstream, not the cause. I captured this one while the app was still running, so ShipIt had not yet given up. The last line in ShipIt_stderr.log:

2026-09-22 23:14:04.786 ShipIt[32823] Detected this as an install request

Eight minutes later that ShipIt process (pid 32823) is still alive and has never reached Beginning installation, while the Maka main process (pid 6917) is still running with no Runtime Host child and a usable window. So the sequence really is "the quit never finishes → ShipIt blocks indefinitely with nothing to read", and the App Still Running Error only appears once the user gives up and relaunches.

Note the ordering, too: the Host exits at 23:14:02 local and ShipIt receives the install request at 23:14:04 — the retirement completes before the hand-off, which is what leaves nothing to restart it.

2. It is intermittent, at least here. The same machine installed an update successfully through the identical path two days earlier:

2026-09-21 15:02:12.237 ShipIt[6808] Detected this as an install request
2026-09-21 15:02:12.665 ShipIt[6808] Beginning installation
2026-09-21 15:02:16.007 ShipIt[6808] Installation completed successfully
2026-09-21 15:02:19.158 ShipIt[6877] Successfully launched application at file:///Applications/Maka.app/

0.43s from install request to Beginning installation, because that quit did finish — and the process it launched is the one that hung on the next update. So the stage that stops settling looks timing- or state-dependent rather than a permanently broken path, which argues for bounding the stages (as #5540 does) over hunting a single deterministic deadlock.

Still present on main. As of 6cb8c5808, app-update-service.ts still unwinds the install handoff only from the catch and the updater's error event, and app-quit-coordinator.ts still awaits prepareToQuit() / cleanup() with no upper bound — so a hand-off that "succeeds" while the process stays alive has nothing to bring the Host back.