fix(cron): correctly run when startingDeadlineSeconds and timezone are set
#13795
Conversation
This file contains 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
Signed-off-by: Alan Clucas <alan@clucas.org>
Joibel
force-pushed
the
cronwf-tz-deadline
branch
from
9fc22c8
to
561bbda
Compare
Joibel
added
area/cron-workflows
prioritized-review
agilgur5
changed the title
startingDeadlineSeconds with timezone fixstartingDeadlineSeconds and timezone are set
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.
Fixes #13786
Motivation
If a CronWorkflow is tested for whether it should run within
startingDeadlineSecondsit tests it in the wrong timezone.This doesn't matter for hourly or minutely CWFs.
This doesn't matter if a CWF doesn't have a timezone associated with it.
This test happens on Informer relist, so if the relist occurs at the wrong time the CWF can be erroneously fired.
This was introduced in #12616 (see linked issue) in version 3.6.
Modifications
The main change is to use
GetSchedulesWithTimezone()rather thanGetSchedules()when iterating over the schedules to check startingDeadlineSeconds.The code was confusing (and confusing before #12616) in that it attempted to modify
timeNow()to be in a local time. This was irrelevant and made spotting the bug harder. I have removed it. Alltime.Timecomparisons are timezone aware, so modifyingtime.Now()usingIn()has no effect on any comparisons made.Verification
Manual testing with a 20second relist interval.
Two new unit tests (in a single function). If you reverse the main modification above both tests will then not pass and give inverse results for the
missedExecutionTimeassertions.These tests will assert if run in Auckland timezone. This could be improved by making the test more complex (pick one of two timezones), but I didn't think this was worthwhile at the moment.
Notes
This PR should not be backported to v3.5 or earlier