test: fix flaky test_scheduler_runs_due_task_and_advances near minute boundaries#209
Open
CyberDefenseOperations wants to merge 1 commit into
Conversation
… boundaries The test forces an every-minute cron task due and sleeps a fixed 0.2s with tick_seconds=0.05. After the first (catch-up) run the scheduler correctly advances next_run to the next minute boundary; when the test happens to start within ~0.2s of a boundary, that boundary falls inside the sleep window and the task legitimately fires a second time, failing 'assert ran == [t.id]'. Harness race, not a scheduler bug (the running-guard and post-run advance are correct). Wait on an event set by the fake runner and stop the scheduler immediately after the first run - the advance is synchronous once the runner returns, so no second tick can fire. Verified 15/15 plus an adversarial shifted-clock repro at the minute boundary.
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
1 participant
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.
The test forces an every-minute cron task due and sleeps a fixed 0.2s with
tick_seconds=0.05. After the first (catch-up) run the scheduler correctly advancesnext_runto the next minute boundary; when the test happens to start within ~0.2s of a minute boundary, that recomputed boundary falls inside the sleep window and the task legitimately fires a second time, failingassert ran == [t.id]with['task-X','task-X'].This is a harness race, not a scheduler bug — the running-guard (
_running_ids) and the synchronous post-run advance are correct, and the second fire is the next real cron occurrence. Reproduced deterministically by shifting the store clock to 0.1s before a minute boundary.Fix: wait on an
asyncio.Eventset by the fake runner instead of sleeping a fixed window, and stop the scheduler immediately after the first run — the advance completes synchronously once the runner returns, so no further tick can fire. Verified 15/15 in a loop plus the adversarial minute-boundary repro; the single-fire and advance assertions are unchanged.