Skip to content

monitor: --collect so a failed verify unit cannot block the next deploy - #326

Merged
anuveyatsu merged 1 commit into
mainfrom
fix-monitor-verify-collect
Sep 14, 2026
Merged

anuveyatsu merged 1 commit into
mainfrom
fix-monitor-verify-collect

Conversation

@anuveyatsu

Copy link
Copy Markdown
Member

Problem

The monitor : Verify the monitor runs task runs systemd-run --unit=wg-monitor-verify --wait with a fixed unit name and no --collect. systemd keeps a transient unit that ends in failed until systemctl reset-failed, so any dry-run that exits non-zero (a transiently unreachable DB, a full disk) leaves the unit lingering — and the next deploy's systemd-run with the same name dies with:

Failed to start transient service unit: Unit wg-monitor-verify.service was already loaded or has a fragment file.

That fails the deploy on a check unrelated to the change being shipped. It blocked the Gemini model-switch deploy (#325) on 2026-09-14 — the leftover unit was from an earlier run — and would block every deploy after any failed verify until cleared by hand.

Fix

Add --collect to the systemd-run invocation so the transient unit is garbage-collected even on failure, freeing the name for the next run. No happy-path behaviour change.

I already cleared the current stale unit on staging-control (systemctl reset-failed), so this deploy should run clean and also carry the #325 Gemini model switch to the execution host (its models.json didn't update when #325's deploy failed mid-play).

🤖 Generated with Claude Code

The "Verify the monitor runs" task runs `systemd-run --unit=wg-monitor-verify
--wait` with a FIXED unit name and no --collect. systemd keeps a transient unit
that ends in `failed` state until `systemctl reset-failed`, so any dry-run that
exits non-zero (a transiently unreachable database, a full disk) leaves the unit
lingering -- and the NEXT deploy's systemd-run with the same name dies with

  Failed to start transient service unit: Unit wg-monitor-verify.service was
  already loaded or has a fragment file.

which fails the deploy on a check that has nothing to do with the change being
shipped. It blocked the Gemini model-switch deploy on 2026-09-14 (the leftover
unit was from an earlier run) and would block every deploy after any failed
verify until someone cleared it by hand.

--collect garbage-collects the transient unit even when it fails, so the name is
free on the next run. No behaviour change on the happy path.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@coderabbitai

coderabbitai Bot commented Sep 14, 2026

Copy link
Copy Markdown

Warning

Review limit reached

Next included review available in 49 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Advanced

Run ID: e2f440e5-8776-4ddb-b943-299beb5e6330

📥 Commits

Reviewing files that changed from the base of the PR and between c3d0e4f and d518f34.

📒 Files selected for processing (1)
  • infra/ansible/roles/monitor/tasks/main.yml

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

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

@anuveyatsu
anuveyatsu merged commit 16b15ca into main Sep 14, 2026
7 checks passed
@anuveyatsu
anuveyatsu deleted the fix-monitor-verify-collect branch September 14, 2026 13:54
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