fix(desktop): quit no longer orphans a backend that is slow to stop#22572

Problem

Quitting the desktop app can leave its backend child running as an orphan. When a backend's graceful shutdown takes longer than the 5 second SIGTERM grace, the app exits anyway. The backend keeps running under launchd (ppid 1), still holding statev2.sqlite and its provider agents, until the next launch cleans it up. On a real install this made quit look hung for over 10 minutes, and an offline database repair could not get the database to itself.

The cause is a timeout race. stopAllPoolInstances waits stop({ timeout: 5s }) per backend. Closing the run scope reaches the spawner's release (terminateProcessGroup): SIGTERM to the process group, wait forceKillAfter (DEFAULT_BACKEND_TERMINATE_GRACE, 5 s), then SIGKILL and up to one more second for the group to exit. The quit wait equals the grace, so it expires first, markComplete lets the app exit, and the pending SIGKILL dies with the process. The updater does the same before quitAndInstall.

Change

DesktopBackendManager exports BACKEND_QUIT_STOP_TIMEOUT, the grace plus 2 seconds to cover the SIGKILL and the spawner's one-second exit wait. Quit (stopAllPoolInstances) and the updater's pre-install stop both use it. The grace is unchanged at 5 s. A backend whose teardown truly never finishes still cannot hold quit past the bound; the existing test for that now uses the new bound.

Scope and approval

A very small, focused fix for an obvious bug: two call sites used a deadline equal to the kill grace, so the force kill could never land before the app exited. No product behaviour or setting changes. Related, and not resolved by this PR: issue #13747 (accepted; backend outlives a crashed main), with its separate open PR #13749 (lifetime pipe). The lifetime pipe does not cover this case, because a backend whose graceful shutdown hangs ignores that signal just as it ignores SIGTERM. Here the desktop is alive and must finish the kill itself.

Verification

• Reproduced on a real dev desktop, built from this branch's base with isolated .t3 state and --use-mock-keychain. I froze the backend with SIGSTOP to stand in for a hung graceful shutdown, then sent NSRunningApplication.terminate to the main pid.
  • Before: main exited at 5 s; the backend was left behind (T, ppid 1) and still alive after 60 s.
  • After: the backend was SIGKILLed at 5 s and main exited at 5 s, with no orphan.
  • With idle, unfrozen state, quit takes about 1 s both before and after, so the normal path is unaffected.
• New test, the quit stop deadline waits for a backend that only exits at the force kill: it calls stop({ timeout: BACKEND_QUIT_STOP_TIMEOUT }), the call both quit paths make, against a backend that finishes tearing down 1 s after the grace. It passes with the change and fails with the old 5 s deadline.
• vp test run src/updates/DesktopUpdates.test.ts src/backend/DesktopBackendManager.test.ts (apps/desktop): 39/39 pass on current main, after #22557 pruned this file. Targeted lint, fmt and desktop typecheck are clean.
• Three independent review rounds, GPT-6.1 Sol (high). Round 1 found the updater path with the same race, fixed here. Rounds 2 and 3, the latter after the rebase, had no actionable findings.
• Not checked:
  • Windows/WSL at runtime. That path uses taskkill /T /F, which kills immediately, so only the outer wait changes.
  • A real updater install.
  • Why a production backend's graceful shutdown hung for minutes. That is a separate server-side question this PR does not change.

Claude Opus 5.5 in Claude Code (T3 Code); reviews by GPT-6.1 Sol in Codex.

🤖 Generated with Claude Code