You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose you have a 5-minute schedule with 1 minute jitter. The next nominal time is 12:20:00, but with jitter it's 12:20:33. Now at 12:20:10 you do an update to the exact same spec. It throws out the previous times and calculates the next times from there. The next nominal time is 12:25:00 now (we're past 12:20:00) and then adds jitter to that. So the run at 12:20:33 is lost.
Expected Behavior
If there is a matching time including jitter after the update time, it should still run, even if its nominal time was before the update time.
Possible Fix
For interval specs, it could just look back one interval, but with calendar specs we can't (easily) look backwards. One idea is to start from the previous action time and start calculating forwards, discarding any times where the actual time (including jitter) is in the past (of the update time). Or better, start from max(create time, last update time, previous action time). We use that same construction as the "retention base" for idle schedules so that makes some sense.
The text was updated successfully, but these errors were encountered:
## What changed?
After an update, the schedule workflow goes back to the previous
action/update and recomputes next times from there, instead of from the
current time.
## Why?
Fixes#4866. Fixes the situation where an update happens in between the
nominal time and the jittered time of an action.
## How did you test it?
new unit test
stephanos
pushed a commit
to stephanos/temporal
that referenced
this issue
Mar 21, 2024
…#5381)
## What changed?
After an update, the schedule workflow goes back to the previous
action/update and recomputes next times from there, instead of from the
current time.
## Why?
Fixestemporalio#4866. Fixes the situation where an update happens in between the
nominal time and the jittered time of an action.
## How did you test it?
new unit test
## What changed?
After an update, the schedule workflow goes back to the previous
action/update and recomputes next times from there, instead of from the
current time.
## Why?
Fixes#4866. Fixes the situation where an update happens in between the
nominal time and the jittered time of an action.
## How did you test it?
new unit test
Actual Behavior
Suppose you have a 5-minute schedule with 1 minute jitter. The next nominal time is 12:20:00, but with jitter it's 12:20:33. Now at 12:20:10 you do an update to the exact same spec. It throws out the previous times and calculates the next times from there. The next nominal time is 12:25:00 now (we're past 12:20:00) and then adds jitter to that. So the run at 12:20:33 is lost.
Expected Behavior
If there is a matching time including jitter after the update time, it should still run, even if its nominal time was before the update time.
Possible Fix
For interval specs, it could just look back one interval, but with calendar specs we can't (easily) look backwards. One idea is to start from the previous action time and start calculating forwards, discarding any times where the actual time (including jitter) is in the past (of the update time). Or better, start from max(create time, last update time, previous action time). We use that same construction as the "retention base" for idle schedules so that makes some sense.
The text was updated successfully, but these errors were encountered: