Preview canary stalls after Ready to restart: quitAndInstall never completes the install

[vishaltandale00]

Problem

The Apple Silicon Preview canary for 0.2.29 to 0.2.30 (run 33679270867) reached "Ready to restart" and then never relaunched into the target. It sat for ~43 minutes and was cancelled.

This blocks Stable promotion, because promotion requires committed canary evidence and the run produced no post-update screenshot and no evidence JSON.

Evidence

Everything up to the install succeeded:

Step	Result
0.2.29 installs from DMG, launches	pass
Discovers 0.2.30 on Preview	pass
Downloads to pending cache	pass
Reports ready, screenshot captured	pass
updater.install() invoked	pass
App quits	never happened
Squirrel installs and relaunches	never happened

seed-update.log ends at:

New version 0.2.30 has been downloaded to .../pending/Relayer-0.2.30-mac-arm64.zip
Creating proxy server for native Squirrel.Mac (fileToProxy=...)
Proxy server for native Squirrel.Mac is listening (address=http://127.0.0.1:49233, ...)

then silence. At job cleanup the runner terminated Relayer, relayer-graph-server, relayer-app-server and two Relayer Helper processes as orphans, so the app was alive and holding its children throughout.

Ruled out

• The Desktop 0.2.29 cannot start on any existing database: search rebuild over-counts edges for project-scoped closures #435 startup bug. The preview-ready screenshot shows the seed at provider onboarding with no thread and no graph content, so the profile had no edges.
• The managed-runtime quit dialog. confirmManagedRuntimeQuit returns true immediately when installer.activeOperations() is empty, which matches onboarding.
• Graph runtime shutdown. #closeResources and #closeHarnessHost are deadline-bounded with force-close fallbacks.
• The recursive temporal chain. Launching packaged 0.2.30 locally with an isolated profile and the chain enabled, then signalling quit, exits in 1 second with all children gone.

Hypothesis

The failure is specific to the quitAndInstall path, which the local quit test does not exercise.

updater.install() calls autoUpdater.quitAndInstall(false, true), which internally requests an app quit. The before-quit handler then calls event.preventDefault() and runs an async shutdown before calling app.quit() itself:

app.on("before-quit", (event) => {
  if (shutdownComplete) return;
  event.preventDefault();
  ...
  await shutdownServices();
  shutdownComplete = true;
  app.quit();
});

Cancelling the quit that quitAndInstall initiated, then quitting separately later, is a fragile coordination with electron-updater's Squirrel handoff. Worth verifying whether the install survives a deferred quit, or whether the updater needs to be told to install after shutdown settles rather than racing it.

Also note shutdownServices() awaits productServer.close(), accountService.close() and providerComposition?.close() with no deadline at that seam; only graphRuntime.close() is bounded. That is a separate latent stall risk even though it was not implicated here.

Why it matters beyond CI

If the packaged updater can reach "Ready to restart" and then fail to install, users clicking Restart to update may silently stay on their current version. That is especially bad for anyone on 0.2.29, which cannot start once their graph contains edges (#435).

Acceptance

• The Apple Silicon canary completes a full seed-to-target update and emits post-update evidence
• quitAndInstall reliably installs when the app performs asynchronous shutdown first
• Shutdown closes that can stall are bounded, or explicitly documented as unbounded by design

[vishaltandale00]

Correction: the before-quit hypothesis is wrong. Native Squirrel never asks for the file.

The original write-up guessed that event.preventDefault() in before-quit broke the quitAndInstall handoff. That is not what happens — before-quit never runs at all, because app.quit() is never reached.

The actual mechanism

Our config sets autoDownload = false and autoInstallOnAppQuit = false.

1. download() fetches the zip itself, starts the local proxy, calls setFeedURL, and dispatches update-downloaded to our UI. Because autoInstallOnAppQuit is false, MacUpdater.doDownloadUpdate resolves here without triggering native Squirrel. Phase becomes ready — this is the "Ready to restart" state in the screenshot.
2. install() calls autoUpdater.quitAndInstall(false, true). squirrelDownloadedUpdate is still false, so MacUpdater.quitAndInstall takes the else branch:

this.nativeUpdater.on("update-downloaded", () => this.handleUpdateDownloaded());
if (!this.autoInstallOnAppQuit) {
    this.nativeUpdater.checkForUpdates();
}

3. Only handleUpdateDownloaded() calls nativeUpdater.quitAndInstall() / app.quit(). It fires only when native Squirrel emits update-downloaded.
4. Native Squirrel never emitted it, so the app waited indefinitely. before-quit, confirmQuit and shutdownServices were never entered.

The proof

MacUpdater logs every proxy hit:

this.server.on("request", (request, response) => {
    const requestUrl = request.url;
    log.info(`${requestUrl} requested`);

In the canary's seed-update.log:

$ grep -c "requested" seed-update.log
0

Zero requests. Native Squirrel.Mac never contacted the local feed URL, and logged no error — the 6 error matches in that log are unrelated com.apple.backupd.sandbox.xpc noise. It silently did nothing.

Also ruled out

• The recursive temporal chain. Packaged 0.2.30 with an isolated profile and the chain enabled exits 1 second after a quit signal, with all children gone.
• Desktop 0.2.29 cannot start on any existing database: search rebuild over-counts edges for project-scoped closures #435. The seed sat at provider onboarding with no graph content.
• A read-only mount. The canary dittos the app out of the DMG into a writable $runtime_directory/Applications before running it.

Two separable problems

1. Product: the restart path can hang forever with no feedback. There is no timeout on the wait for update-downloaded and no error surface. A user who clicks "Restart to update" and hits this sits at "Ready to restart" indefinitely with no indication anything failed. That is worth fixing regardless of why Squirrel stayed silent, and it matters most for anyone on 0.2.29, which cannot start once their graph contains edges.

2. Why Squirrel stayed silent. Still unproven. Candidates worth checking: quarantine leading to App Translocation (the canary never clears com.apple.quarantine and never asserts the app is running from the path it installed to), a macos-15 runner image change since the last green canary on 2026-08-21, or Squirrel declining to update an app outside /Applications.

Suggested acceptance additions

• The wait for native update-downloaded is bounded, and a timeout surfaces a real error in the updater state
• The canary asserts the running app path matches the installed path, so translocation fails loudly instead of silently

[vishaltandale00]

Correction: the update path works. It is slow, and the canary's wait has a second gap.

An earlier comment claimed the stall reproduced on a real Mac and was therefore a product bug. That was wrong. I checked roughly a minute after install() and mistook latency for a hang.

Local reproduction, run to completion

Installed 0.2.29 from its signed DMG into a writable directory exactly as the canary does, launched it with an isolated profile, and drove desktop/release/electron-cdp-canary.mjs --mode update against 0.2.30:

Event	Time
Updater reports ready	22:37:09Z
Squirrel.Mac requests the file through the proxy	~22:41Z
Download completed to: .../ShipIt/update.NHMaAnW/...	22:41:01Z
nativeUpdater.update-downloaded, proxy closed, app quits	immediately after

The installed bundle afterwards reports CFBundleShortVersionString = 0.2.30. The 0.2.29 to 0.2.30 update completes.

So quitAndInstall is not broken, before-quit is not deadlocked, and there is no missing error path in the sense previously described. Native Squirrel simply takes minutes to act after checkForUpdates(), during which the app legitimately sits at "Ready to restart" with no output.

A real gap the reproduction did surface

The relaunched 0.2.30 never wrote a target trace:

versions in trace: ['0.2.29']

Squirrel relaunches through LaunchServices, which does not inherit the launching shell's environment, so RELAYER_DESKTOP_CANARY_LOG was lost. The canary works around this with launchctl setenv, which my reproduction did not replicate, so this specific result is expected here and does not by itself indict the canary.

It does mean wait_for_target_trace depends on that launchctl setenv surviving the relaunch. If it does not survive on the runner, the canary would wait out its full 1800s while a successful update sits undetected.

What remains unexplained

On the runner, seed-update.log recorded zero proxy requests across two runs of roughly 45 minutes each. Locally Squirrel requests after about 4 minutes. Either something prevents Squirrel from acting on the hosted runner, or the evidence was preserved before it got there.

Both runs ended as cancelled rather than failure, even though wait_for_target_trace should have failed at its 1800s deadline. Reconciling that timing is the next thread to pull.

Revised acceptance

• Determine whether Squirrel.Mac ever requests the proxy on a hosted macos-15 runner, by preserving seed-update.log on timeout and asserting on request count
• Confirm RELAYER_DESKTOP_CANARY_LOG survives the Squirrel relaunch, so a successful update cannot go undetected
• Surface progress between "ready" and relaunch, since several minutes of silence is normal and currently indistinguishable from failure