Skip to content

fix(status): do not go quiet on a host whose units predate run records - #158

Merged
vishr merged 1 commit into
mainfrom
fix/schedule-status-upgrade-gap
Sep 6, 2026
Merged

fix(status): do not go quiet on a host whose units predate run records#158
vishr merged 1 commit into
mainfrom
fix/schedule-status-upgrade-gap

Conversation

@vishr

@vishr vishr commented Sep 6, 2026

Copy link
Copy Markdown
Member

What this changes

Found while preparing the first release that carries #156, and it should not ship as it stands.

Run records are written by the generated unit, so a host still running units from before that change has none. ob status had stopped querying systemd's Result and ExecMainStatus entirely and derived its verdict only from records. The consequence is that upgrading ob on the workstation — no deploy, nothing changed on the host — turns a failing scheduled job into a clean report and an exit 0, until someone happens to run ob schedule apply.

That is the exact direction the feature exists to close, arriving as a side effect of installing it.

With no records at all, systemd's retained result is the only evidence there is, so status uses it and says what it is looking at:

schedule nightly-dump last run failed: timeout (exit 143); no run record — run `ob schedule apply` so runs are recorded ⚠

Once records exist they remain the verdict, and a stale systemd result raises nothing.

Why this is correct

  • The fallback fires only when a job has no records at all, so it cannot produce the contradictory pair of answers that made the record the sole verdict in the first place.
  • TestScheduleStatusFallsBackToSystemdWhenNoRecordsExist covers the pre-upgrade host; TestScheduleStatusPrefersRecordsOverSystemdResult pins a retained Result=timeout losing to a success record.
  • The scheduling guide's upgrade section now states the transition rather than leaving it to be discovered.
  • just check and just lint pass.

Effect on the safety envelope

Restores a divergence signal that #156 removed for hosts that have not been reconciled yet. It only adds an issue where status was silent; it cannot clear one.

Checklist

  • just check passes locally.
  • Tests cover the new behaviour, including the failure paths.
  • Generated documentation is current (just check verifies this).
  • I have accepted the CLA, or will when the bot asks on my first pull request.

https://claude.ai/code/session_013MqwrF5NA179khDtEQdib5

Run records are written by the unit, so a host still running units from before
this change has none. `ob status` had stopped reading systemd's own result
entirely, which meant upgrading `ob` — with no deploy, no change on the host —
turned a failing scheduled job into a clean report and an exit 0. That is the
one direction this feature exists to close.

With no records, systemd's retained result is the only evidence there is, and
status uses it and says so: the issue names the failure and points at
`ob schedule apply`, which is what starts the records. Once records exist they
remain the verdict, and a stale systemd result raises nothing.

Claude-Session: https://claude.ai/code/session_013MqwrF5NA179khDtEQdib5
@vishr
vishr merged commit 1ba510c into main Sep 6, 2026
5 checks passed
@vishr
vishr deleted the fix/schedule-status-upgrade-gap branch September 6, 2026 15:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant