Skip to content

[RELEASE] A daemon restart that can actually repair the daemon (carries #6401, #6402) #6403

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
vivekchand merged 1 commit into from
Oct 14, 2026
Merged

[RELEASE] A daemon restart that can actually repair the daemon (carries #6401, #6402) #6403

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,12 @@
## Unreleased

### Fixed: the stalled-collector banner stops advising a command that cannot work

- **Why:** when the collector reports no progress for 90 seconds the dashboard shows a red banner, and on macOS it said to run `launchctl kickstart -k`. That restarts the job definition launchd already holds in memory and never re-reads the file, so it cannot repair the most common reason the collector goes quiet: a background helper pinned to a Python that can no longer load ClawMetry. On the node this was found on it had run twelve times in a row and failed every time, which is the only outcome it could have had. The banner was handing the user the one command guaranteed not to help while the helper stayed dead. The copy was also macOS only, so everyone else was told something was wrong and given nothing to do about it.
- **What:** the banner now says the background helper may have stopped, and points at `clawmetry sync --restart` to start it again and `clawmetry status` to see what it reports. The restart is the command that actually re-registers the job and re-pins it after the fix above, and the status command reported this condition correctly throughout. Both work on every operating system.
- **Verified:** 5 new tests in `tests/test_stale_daemon_banner_advises_a_command_that_works.py` pin that the advice names the restart and the status commands, is not macOS only, and that no line of the shipped frontend reintroduces the old one. All five were run against the previous copy first and all five failed there. 137 pass across the English, i18n, launchd and banner suites, and the frontend parses under node.
- **Limits:** this corrects the advice the banner gives. It does not change when the banner appears, and a helper that cannot start still needs the operator to run the command.

### Fixed: a restart that could not repair the daemon, and said it had

- **Why:** the sync daemon's LaunchAgent pins an absolute interpreter path at install time. When that interpreter stops being able to import `clawmetry`, the running daemon survives (Python holds imported modules in memory) and then dies at the next restart, after which every relaunch fails instantly. The documented repair, `clawmetry sync --restart`, could not fix it. `launchctl bootstrap` refuses a label that is already registered, and the legacy `load -w` fallback also fails while still exiting 0, so no return code could see it. The corrected plist landed on disk and launchd kept running the definition it already held in memory. The command then printed "Running in the background. Your data is syncing to the cloud." over a daemon that was crash looping. Found on a founder node on 2026-10-14: the daemon had been dead for about five hours while the dashboard showed "Step: starting", and Assistant, Setup and every other view that reads through the daemon rendered an empty state with no indication why.
Expand Down
Loading