aw-notify exits fatally when aw-server is unreachable at startup (crash-loops under desktop managers) #47

Summary

When aw-notify starts while aw-server is not yet accepting connections, it exits fatally instead of waiting/retrying. Under the desktop module manager (aw-tauri/aw-qt) this becomes a crash loop: the module is restarted with 2s/4s/8s backoff, gives up after 3 attempts, and the user gets a "module quit after 3 auto-restart attempts" dialog. On desktop the notification module is commonly (auto)started alongside aw-server, so a server that is slow to bind is enough to trigger it.

Evidence (user report)

ActivityWatch/activitywatch#1526 — v0.14.0 and v0.14.1, Linux AppImage:

• Connection refused when aw-notify polls /api/0/info.
• Crash dialog: module quit after 3 auto-restart attempts within 10 minutes.
• No new aw-notify log file is written for the crash.
• The standalone aw-notify-rs v0.2.0 binary works for the same user.

Root cause

src/main.rs → run_app():

let client = aw_client_rust::blocking::AwClient::new("127.0.0.1", port, client_name)
    .map_err(|e| anyhow!("Failed to create client: {}", e))?;
client.get_info()?;                       // <-- any connection error here is fatal
let config = try_load_server_config(&client, config);
if !config.enabled { /* opt-in gate */ return Ok(()); }

get_info()? propagates on connection-refused; main() then logs Fatal error: … and returns Err, so the process exits non-zero. The surrounding comment in the pre-opt-in code said "Wait for server to be ready (like Python's wait_for_start)", but the Rust rewrite has no actual wait/retry (the Python implementation did).

Suggested fix

Either of these would make startup robust:

1. Bounded wait-for-server at startup — poll get_info() with a short backoff for a bounded window (e.g. ~10–15s) before treating it as fatal. This window matters because the desktop manager's own retry budget is only 3 attempts, so the module must outlast a slow server bind itself.
2. Make the startup probe non-fatal — log the failure and continue; the existing server_monitor_thread already tracks SERVER_AVAILABLE and reconnects.

Option 1 matches the original Python wait_for_start behaviour and is the smallest change.

Repro

# With no aw-server listening on :5600
aw-notify --output-only
# -> "Fatal error: …" and a non-zero exit (no retry)

Filed from the ActivityWatch triage flow after user report ActivityWatch/activitywatch#1526. Tagging so the desktop crash-loop symptom is tracked separately from the opt-in architecture work in ActivityWatch/activitywatch#1435.