Skip to content

Wait out schedule occurrences before recording schedule-catalog (#1102) - #1145

Merged
rmcdaniel merged 1 commit into
mainfrom
fix/server-1102-schedule-occurrence-guard
Nov 11, 2026
Merged

rmcdaniel merged 1 commit into
mainfrom
fix/server-1102-schedule-occurrence-guard

Conversation

@rmcdaniel

Copy link
Copy Markdown
Member

Fixes #1102 with the issue's preferred option 1 (no fixture change).

The schedule-catalog fixture keeps live daily schedules. A recording that crossed a natural occurrence let the reference server fire it, so every response differed from the reviewed PHP expectation and the corpus job failed for any change (observed at 09:00:00Z on 2026-11-08, merge group of #1101).

Before recording any fixture with schedule_catalog, scripts/conformance/server-parity.mjs now calls waitOutScheduleOccurrences. If one of the fixture's occurrences falls within the next 10 minutes, it waits until one minute after it and logs waiting Ns for a schedule occurrence to pass before recording (Server #1102). The occurrences are 00:00 UTC, 06:00 UTC, 04:00 America/New_York and 03:00 Europe/Budapest, DST-aware. Both the main corpus (MySQL/PostgreSQL) and the separate SQLite recording go through this runner. The worst-case cost is about 11 minutes on a run that would otherwise have failed. Assertions and the reviewed expectation are unchanged.

Checks: new tests/Unit/ServerParityScheduleOccurrenceGuardTest.mjs (the observed 09:00Z EST crossing, EDT/CEST/CET shifts, UTC intervals, margin, far-from-occurrence = no wait), 4/4; ServerParityRunnerTest + ServerParityScheduleContractTest 431/431.

🤖 Generated with Claude Code

The schedule-catalog fixture keeps live daily schedules. A recording that
crossed one let the reference server fire it, so every response differed
from the reviewed expectation and the corpus failed whatever the change
(#1102). Before that fixture records, the runner now waits until one minute
after any of its natural occurrences (00:00 and 06:00 UTC, 04:00 New York,
03:00 Budapest, DST-aware) that falls within the next ten minutes, and logs
the wait. No fixture or expectation changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@sonarqubecloud

Copy link
Copy Markdown

@rmcdaniel
rmcdaniel added this pull request to the merge queue Nov 11, 2026
Merged via the queue into main with commit a35367a Nov 11, 2026
63 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

schedule-catalog parity fixture fails when a recording crosses a schedule's wall-clock occurrence

1 participant