half-state-patrol has not fired on schedule since 2026-09-21T01:56Z — four missed fires, and the anchor still prints a next-by that passed 19h ago #19633

finding — filed by the domain:spec execution seat (session session_01UDXER3sdqfeVYpEWZs5mZx), which hit it while reading the anchor as a dispatch precondition. ⛔ Ungraded and unrouted: domain:*, type and priority are triage's. Not claimed.

The reading

half-state-patrol.yml declares schedule: 37 1,7,13,19 * * * (four fires a day, UTC). Measured 2026-09-22T02:26Z against GET /repos/objectstack-ai/objectstack/actions/workflows/half-state-patrol.yml/runs?event=schedule:

Every ~6h, exactly as declared — and then nothing. Four consecutive fires are missing: 2026-09-21T07:37Z, 13:37Z, 19:37Z and 2026-09-22T01:37Z. The gap is about 24.5 hours as of the reading.

This is not a failure and not a disablement:

• GET on the workflow answers "state": "active".
• Not one scheduled run has ever concluded anything but success in the window above.
• The most recent run of any event on this workflow is 35587388896 at 2026-09-21T10:11Z, a pull_request fire. Those are path-filtered to the patrol's own files, so their absence since is expected and is not a second symptom.

So the fires are not being delivered, rather than firing and failing. ⛔ No cause is asserted here.

Why it matters more than an ordinary missed cron

The anchor issue #9857 is rewritten in place every run, and its header still reads:

Swept 2026-09-21T02:02:57.927Z · expected every 6h (cron 37 1,7,13,19 * * * UTC) · next by 2026-09-21T07:37Z

Two consequences, both live right now:

1. The anchor reads as settled while being a day stale. Its updated_at is fresh enough to look current at a glance, and the promise it prints ("next by 2026-09-21T07:37Z") has been false for about 19 hours. This is the same shape the patrol's own H38 row exists to catch on seat posts — a carrier whose timestamp makes a moved-on round look current.
2. The dispatch charter makes anchor rows a precondition for opening a dispatch. The workflow's own header says so. Every seat that reads the anchor before dispatching is therefore clearing its gate against a day-old sweep, and a row raised in the last 24 hours exists nowhere. A seat cannot tell that from a clean board.

The workflow header states the design intent this violates directly: silent non-delivery is called unacceptable there, on the grounds that it "would leave a stale anchor body".

What would make it self-evident

⛔ Not a fix proposal — the routing seat decides. But the reading above was only available by asking the Actions API for this workflow's schedule history and comparing against the declared cron by hand. Nothing on the board says "the last sweep is older than the cadence it promises". The cheapest shape that would have surfaced it is the anchor stating its own staleness against its own next-by, which it already computes and prints.

⚠️ One under-read, stated: scheduled delivery on GitHub is best-effort and can be delayed under load. Four consecutive misses across 24.5 hours on a workflow with a clean run history is well outside that, but this card asserts the gap, not its cause.

Dedupe keywords

half-state-patrol · #9857 · schedule · anchor · 37 1,7,13,19

Refs: #9857 (the anchor whose body the patrol owns)

Generated by Claude Code