Freeze the clock in test_run_automations - #2456
Merged
Merged
Conversation
Context: - The test invokes `flexmeasures jobs run-automations` twice and asserts that the second invocation finds nothing due, which only holds while both land in the same clock minute. - The automations it sets up recur every minute, so once a slow first invocation crosses a minute boundary, they are legitimately due again and the assertion fails. Seen on Python 3.11 in CI. Change: - Froze the clock with the existing freeze_server_now fixture, as the neighbouring catch-up test already does, so the test no longer depends on how long its first invocation takes. Signed-off-by: F.N. Claessen <felix@seita.nl>
Documentation build overview
|
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.
Description
test_run_automationsinvokesflexmeasures jobs run-automationstwice and asserts that the second invocation reports nothing due, under the comment "running again within the same minute does not queue jobs twice". That only holds while both invocations land in the same clock minute.The two automations it sets up recur every minute (
* * * * *). The first invocation queues real forecasting jobs, so on a slow runner it can cross a minute boundary — after which both automations are legitimately due again, and the assertion fails:Nothing is wrong with the behaviour under test: queueing again in a new minute is exactly what an every-minute automation should do. The test is simply time-dependent, and fails at random.
Observed on Python 3.11 in CI on #2299, but it is not specific to that PR — the assertion is on
main, so any PR can hit it.Change
Froze the clock with the existing
freeze_server_nowfixture, which the neighbouringtest_run_automations_catches_up_once_after_downtimealready uses for the same reason. No production code is touched.How to test
No changelog entry, as this changes a test only.
Sign-off