Repository navigation
Stop the schedule fixture probe from applying a published PHP write twice - #674
Merged
Merged
Conversation
Main's Shared Server fixtures fail schedule-policies on native SQLite intermittently, with a different step each time: a 503 on DELETE, a first skip trigger reported as skipped, and a 404 on the second quota trigger. The contract printed only positions and outcomes, so the cause was not in the log. A status difference now names each differing step with its response, and an outcome difference shows the trigger responses with their reasons.
The schedule-policies and schedule-catalog differences on main come from the published PHP reference, not native: no PHP pass line precedes them. PHP on SQLite can report "database is locked" for a write that already committed (the started run's task is queued after the trigger's transaction), and the probe sent the write again. A retried trigger then read as skipped (its first run was running), and a retried quota trigger used the second action, so the next trigger found the schedule deleted. A write is now sent again only when its schedule reads exactly as it did before the write. Otherwise the failure is recorded, and the recorded lock replays the whole sequence in a new namespace, now up to five times. Reads are still retried. Native never reports this lock. In a local run of the CI step on these sources, published PHP passed both schedule fixtures (five safe retries and one replay for schedule-policies), and native matched them on the first attempt.
This was referenced Oct 22, 2026
Route pinned runs by their recorded definition like PHP; run every fixture check before failing
#667
Merged
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Main's Shared Server fixtures fail
schedule-policies(orschedule-catalog) intermittently, at a different step each time:29fb77e3(job 119962357942)POST schedules/quota/trigger, returned 404 instead of 200b2999cac9policy-skiptrigger returnedskippedinstead oftriggeredDELETE schedules/policy-skipsteps returned 503Cause. These differences come from the published PHP reference, not native. When native differs, the step log first shows
{"outcome":"pass","target":"php"}and…"embedded"}; none of these failures has those lines.A local reproduction of the CI step shows the mechanism:
database is lockedfor a schedule write that had already committed. The started run's task is queued after the trigger's transaction.skipped, because its own first run was still running;Change.
Evidence, local runs of the CI step:
schedule-catalogafter three replaysschedule-policiestook five safe retries and one replay;schedule-catalogpassed first time. Native's only difference is the known frozensignals-before-worker; it matched both schedule fixtures on attempt 1 with no retries.The schedule contract tests pass (20/20 and 18/18), including the new message and attempt-bound cases.