fix(daemon): detect a stale binary and self-restart instead of running outdated in-process job logic

[getappz]

Summary

Adds a background watchdog so a long-running agentflare daemon self-restarts once the on-disk binary it was launched from changes, instead of silently continuing to execute stale in-process job logic forever.

Why

This is the second confirmed occurrence of the same root cause:

• First (a vent, cancelled as noise but the finding was real): a dispatched job failed instantly with No such file or directory because current_exe() resolved to /home/avihs/.cargo/bin/agentflare (deleted) after a rebuild replaced the binary the daemon started from.
• Second (item [ponytail#532] Persona wording: lazy = less work for same result #66, PR feat(daemon): resource-aware work_max_concurrency (CPU + memory, ported from codegraph's resolver-pool) #436): the daemon's in-process job runner (item Add Scoop manifest for v1.0.1 #19) did real, verified work, but the running daemon predated commit fix(work): dispatched jobs leave real edits uncommitted, reported as success #431's auto-commit-on-done fix — the safety net specifically built to catch this exact scenario (item [ponytail#240] Pluggable persona system — Persona trait for /jedi, Architect, etc. #57) — so the work was silently left uncommitted and the item was wrongly marked completed with no PR. Had to be manually rescued.

Because work dispatch is in-process, a rebuild/merge no longer makes dispatch fail loudly — the daemon can run arbitrarily stale logic indefinitely with zero self-awareness, and failures are silent and hard to notice, not loud crashes.

What changed

• src/daemon.rs: BinarySnapshot captures the on-disk binary's path/mtime/size via current_exe() at daemon startup. is_stale() is a cheap stat()-based comparison (mtime/size changed, or the file is gone). respawn_from_stale() cleans up pid/lock files first (so the replacement's own is_daemon_running() gate doesn't mistake the exiting process for a live one), spawns a replacement daemon via the same serve --_foreground-daemon invocation start_daemon/the installed systemd/launchd units use, and exits. 3 unit tests cover is_stale for unchanged/replaced/deleted files.
• src/dashboard/server.rs: spawn_binary_staleness_watchdog() ticks every BINARY_STALENESS_CHECK_INTERVAL (60s) and calls respawn_from_stale once the snapshot goes stale. Wired into run() right after the worker pool starts.
• In-flight-job risk: respawn_from_stale deliberately does not wait for jobs the WorkerPool may have running. This is documented as safe rather than a new gap — reconcile_orphaned_jobs (item feat: add eyre + color-eyre for rich error reporting #40) already makes an abruptly-dead daemon's in-flight jobs fail loud and release their claim, and a self-triggered respawn is just another instance of that same crash/kill-9 case it was built for.

Test plan

• cargo build --bin agentflare — clean
• cargo test --bin agentflare — 1263 passed; 1 pre-existing unrelated failure (mcp_prompts::tests::optimize_review_returns_full_skill_body, root-caused to a sandbox artifact — a read-only ~/.local/state mount rejecting flare-code's active-mode file write, unrelated to this change and reproducible on unmodified files). All 3 new binary_snapshot_tests pass.
• End-to-end respawn path exercised for real: started the built binary as a foreground daemon in an isolated AGENTFLARE_HOME_OVERRIDE/XDG_RUNTIME_DIR sandbox, replaced the on-disk binary via rename (same shape as update::swap::replace_binary), and confirmed the watchdog detected the change and called respawn_from_stale within one 60s tick — old process pid gone, pid file updated to the new process, cleanup performed as designed.

Closes #68

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 7 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 80997352-2dbd-46be-8da4-3c9608f46025

📥 Commits

Reviewing files that changed from the base of the PR and between 1d7d678 and 1317909.

📒 Files selected for processing (2)

• src/daemon.rs
• src/dashboard/server.rs

---

_{Comment @coderabbitai help to get the list of available commands.}