Desktop exit logs omit the shutdown request source

[BradGroux]

Summary

Desktop shutdown diagnostics do not identify what requested the exit. This makes an orderly _exit(0) look like a spontaneous crash when Cap disappears during recording or editor work, and it prevents the application log from distinguishing an app-menu Quit, native macOS/Dock termination, tray Quit, runtime exit, or Unix signal.

I hit this while investigating repeated user-visible "crashes" on the signed Cap 0.5.9 macOS build. There were no Cap .ips, .crash, .hang, or .spin reports in macOS DiagnosticReports. A controlled Quit during an active Studio recording produced FeedLocked warnings for both microphone and camera cleanup, then the 0.5.9 process performed its hard exit with status 0. The Cap log showed cleanup, but only the macOS unified log established that the exit originated from a Quit AppleEvent/menu action.

The recording/finalization admission guards merged in #2172 address the unsafe 0.5.9 lifecycle behavior on current main. This issue tracks the remaining observability gap: future reports still cannot be classified from Cap's own logs.

Reproduction

1. Launch the macOS desktop app.
2. Start a Studio recording or open an editor.
3. Request Quit from the app menu, Dock/native termination path, tray, runtime, SIGTERM, or SIGHUP.
4. Inspect cap-desktop.log.

Actual result

Direct shutdown paths converge on request_app_exit without recording the caller. The log can show cleanup and a clean hard exit, but not why shutdown began. On 0.5.9, an admitted Quit during recording additionally reached feed cleanup while the microphone and camera were still locked.

Expected result

Every graceful exit attempt should log a stable, structured source before admission checks. Blocked requests should also retain that source in the same diagnostic sequence. A report can then be classified from Cap logs alone without depending on short-lived macOS unified-log history.

Root cause

The app menu, macOS applicationShouldTerminate:, tray menu, Tauri ExitRequested, SIGTERM, and SIGHUP paths all call the same source-less request_app_exit(AppHandle) function. The runtime event has a generic pre-log and the signals have separate text logs, but the native/app/tray callers have no equivalent attribution and no common field.

Environment and evidence

• Cap: signed stable 0.5.9; compared against main at 82519d2a42a2336545a9f30133330f4d5e10ad0a (0.6.0 source)
• macOS: 26.6.2, Apple silicon M4, 24 GB RAM
• Audio: Focusrite Scarlett Solo USB, negotiated at 192 kHz stereo and resampled by Cap to 48 kHz mono
• Camera: Logitech BRIO, 1280x720 at 30 fps
• Controlled 0.5.9 Quit evidence: microphone and camera cleanup returned FeedLocked; process exit was voluntary status 0; no Apple crash report was created
• Current-main lifecycle verification: cargo test -p cap-desktop --test exit_shutdown passes all 21 tests, including recording/finalization refusal and Quit-during-Stop coverage
• Local current-main app bundle built, installed, and launched successfully

No recording names, local media paths, account data, or service URLs are included here.

Proposed fix

Thread a typed exit source through request_app_exit and emit it as structured tracing data at the start of every graceful exit attempt.

[linear]

CAP-801

[BradGroux]

Field validation from the diagnostic build

The newly attributed exit log made it possible to resolve a reported "random crash" after deleting a recording.

This event was not a native crash:

• Deleting the recording closed the editor window at 20:50:40.337 local time.
• Vorssaint 3.3.2, with its Auto Quit feature enabled, sent Cap a standard aevt/quit AppleEvent at 20:50:41.996.
• Cap received the Quit event at 20:50:41.997 and the diagnostic build logged source=MacOsNativeTermination.
• Cleanup completed in 1 ms and macOS recorded the process exit as voluntary with status 0.
• No Cap .ips, .crash, .hang, or .spin report was generated.

The local remediation was to add Cap's bundle identifier, so.cap.desktop, to Vorssaint's Auto Quit exceptions while leaving Auto Quit enabled globally. After closing Cap's last visible window and waiting four seconds, the same Cap PID remained alive and its Capture window reopened normally.

This confirms the original issue's diagnostic gap: without the exit-source field, a clean external Quit is indistinguishable from a spontaneous app disappearance in Cap's own logs. No recording names, paths, or account data are included here.