If a CronWorkflow is tested for whether it should run within startingDeadlineSeconds it 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 than GetSchedules() 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. All time.Time comparisons are timezone aware, so modifying time.Now() using In() 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 missedExecutionTime assertions.
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
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