fix(spine): the daily journey was watched by a clock that could not see it #5593
ccantynzAI Reviewcommented 1d ago
AI Triage
(no summary)
Priority: medium Risk area: mixed
Suggested labels: (no label suggestions) Suggested reviewers: (no reviewer suggestions)
Suggestions only — nothing has been applied. The PR author stays in control.
gluecron[bot]🤖 botAI Reviewcommented 1d ago
AI review unavailable
The platform's AI balance is exhausted, so AI generation is temporarily unavailable. Nothing was lost. You can queue this as a repair for the internal agent from the repository's Health page, or try again once the balance is restored. The PR is otherwise unchanged.
Cross-repo impact
See what breaks downstream if this PR merges.
⮌ Merged
This pull request was merged into main.
c comment · e edit title · m merge · a approve · r request changes · ? shortcuts
Two defects, one subject: the check covering register → repo → PAT → push → PR → merge, which is the only end-to-end proof this platform has.
1.
doctor:journeyscould never notice it stoppedThat check takes
MAX(checkedAt)across everyjourney:*row. The five-minute journeys keep it fresh, so a daily journey folded into the same bucket can never go stale.Measured 2026-08-31:
journey:first-runhad not run for 9 hours whiledoctor:journeysread "newest row 1s old (max 15m)". Had it died permanently, that watcher would have stayed green forever.A daily check measured against five-minute siblings isn't being watched — it's being averaged out. It now has its own row and its own budget: 30h, not the 3×-cadence used for the fast checks, because three days of blindness on this one is too long and a full day with no run is exactly the thing worth knowing.
2. "Daily" never described reality
The interval gate read
_lastFirstRunJourneyAt— a module variable, so it reset to0on every restart, and autodeploy restarts this container whenever main moves.On 2026-08-30 the journey ran six times in four hours, once per deploy, and the 24h schedule had almost certainly never fired on its own. AlecRae documented the same shape from the other end: a daily job that never ran at all because the process restarted every 15 minutes.
An in-process timer in a frequently-restarted process is not a schedule.
synthetic_checksalready records every run, so the real answer was one query away. The in-process value stays as a fallback: if the read fails we keep today's behaviour rather than either spamming journeys or silently never running one.Tests
Pin the bug itself — a stale daily journey beside fresh siblings must go red while
doctor:journeysstays green — plus the two ways this becomes noise: 26h is normal rather than dead, and never-run is its own state, not fresh.Verified by mutation: folding the daily check back in with its siblings fails the suite.
Note
Neither defect was reported by anything. Both were found by asking why a number looked wrong — the same way the rest of today's were.