bvandeusen/FabledSteward
1
0
Fork 0
Code Issues 1 Pull Requests 1 Actions Packages Projects Releases Wiki Activity

fix(ansible): overlapping runs: one per host, one per schedule, one action run per alert rule (#5158)
CI / lint (push) Successful in 3s
Details
CI / unit (push) Successful in 1m27s
Details
CI / integration (push) Failing after 1m1s
Details
CI / publish (push) Skipped
Details

Browse Source 
- One run per host: start_run claims every host it touches (addresses read
  from the inventory Steward wrote; a source's own inventory file is claimed
  as that file) before it takes a run slot. The claim is all-or-nothing. A run
  waiting on a host shows queued and names the run it waits for, honours a
  cancel, and fails after HOST_WAIT_SECONDS (1 h) with which host and run.
- A due schedule whose previous run is still queued or running skips the
  firing: last_run_at moves on, last_run_id still names the run going, and
  last_error says "Skipped: the previous run was still going". The Schedules
  page shows that beside the run (muted), and a launch error in red.
- An alert rule that fires while the action run from an earlier firing is
  still going starts no new run; the event says so and names the run. An
  in-process set closes the gap between the check and the run being linked.
- docs/core/ansible.md: queued/cancelled statuses and the overlap rules.

Tests: tests/core/test_ansible_overlap.py (claim keys, waiting, all-or-nothing,
cancel, deadline) and tests/integration/test_ansible_overlap.py (two real
runs on one host take turns; schedule skip then fire; alert action skip then
start).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
bvandeusen
2026-10-06 21:24:51 -04:00
co-authored by Claude Opus 5.5
parent edcfa4d3db
commit 3c24c633df
9 changed files with 514 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files
steward/mcp/tools/automation.py
+4 -2
View File
@@ -527,8 +527,10 @@ async def list_schedules() -> dict:
`check: true` schedules are dry runs that never change anything.
`last_error` is set when a firing could not start at all (a source or
playbook that went away); a run that started and failed shows in
`last_run_status`, and get_ansible_run(last_run_id) has its log.
playbook that went away), or was skipped because the schedule's previous
run was still going (then `last_run_id` still names that run). A run that
started and failed shows in `last_run_status`, and
get_ansible_run(last_run_id) has its log.
"""
async with db_session() as db:
scheds = await _schedules(db)