[macos] Process crashed without error

[ErikBjare]

Watcher process suddenly died after running okay for weeks (last commit, from terminal). Lost 2h of data.

Last messages:

2024-02-14 11:50:18 [aw-watcher-window-macos] [DEBUG] [heartbeat] bucket: aw-watcher-window_erb-m2.localdomain, timestamp: 2024-02-14 10:50:18 +0000, pulsetime: 1.7, app: Alacritty, title: [0:mono-gpt-engineer] ~/P/m/app (/Users/erb/Programming/mono-gpt-engineer/app), url:
2024-02-14 11:50:18 [aw-watcher-window-macos] [DEBUG] sending old heartbeat for merging
2024-02-14 11:50:23 [DEBUG]: queue path '/Users/erb/Library/Application Support/activitywatch/aw-client/queued/aw-watcher-window.v1.persistqueue'  (aw_client.client:418)
⏎

Exit code 0.

[BelKed]

Started to happen to me also... Not sure what's happening here :(
Perhaps it could be fixed by #105?

[claudiu-bargianu]

The thing crashed for me mid work day too. Happened yesterday on 23feb and today. Tahoe 26.3

[TimeToBuildBob]

This is a tricky one — exit code 0 with no error output suggests the process received a clean signal (SIGTERM) or hit an unhandled nil/optional that caused an immediate exit without a crash report.

Given the symptoms (silent death after running for hours/days, last output is a normal heartbeat), a few possible causes:

1. macOS process management: macOS can terminate processes it deems inactive or resource-heavy, especially during thermal throttling or memory pressure. This usually happens silently with exit code 0. Check Console.app → system.log around the time of the crash for any jetsam or thermalmonitor entries.

2. Swift nil unwrap in the watcher binary: The related issue [macos] Process crashes with Unexpectedly found nil while unwrapping an Optional value #100 reports explicit nil unwrap crashes. If the watcher encounters a window state that triggers a nil unwrap in a non-debug build, it could exit cleanly depending on how the error propagates. PR [macos] Improve handling of missing application attributes #105 (improved handling of missing application attributes) may address this.

3. aw-client queue path message: The last log line shows the client accessing its persistent queue, which happens when the server connection drops. If the client's reconnection logic fails fatally, it could explain the exit.

For anyone experiencing this: Check if aw-qt is managing the watcher (it will auto-restart crashed watchers). If running standalone, wrapping it in a restart loop or using launchd with KeepAlive would prevent data loss from crashes.

The 2h data gap suggests the watcher died but its queue didn't flush. Events in ~/Library/Application Support/activitywatch/aw-client/queued/aw-watcher-window.v1.persistqueue might be recoverable if they were queued before the crash.

[ErikBjare]

Check if aw-qt is managing the watcher (it will auto-restart crashed watchers).

In these particular cases aw-qt has not been restarting the watcher for whatever reason (and additionally requires right-clicking trayicon -> module -> click aw-watcher-window menu item to restart -> notice it's still not running -> click again -> starts, this is a related but separate bug)

Address all the aw-qt issues in a PR. I'm working on getting #105 merged.

[TimeToBuildBob]

Opened ActivityWatch/aw-qt#121 to address the aw-qt module management issues:

1. Two-click toggle: toggle() now checks is_alive() instead of the started flag, so clicking a crashed module immediately restarts it (no more click-once-to-clear, click-again-to-start)
2. Auto-restart: check_module_status() was only running once at startup due to a scheduling bug (it scheduled rebuild_modules_menu instead of itself). Now properly runs every 5s and auto-restarts crashed modules up to 3 times with tray notifications
3. Dialog restart button: Fixed missing testing parameter