Do not fast forward rrule if count is set (#15696)

Fixes a bug where a schedule that was created
to run only once will continue to run repeatedly.

e.g. an rrule with
dtstart 20240730; count 1; freq MINUTELY

This job will run on 20240730, and should never
run again.

However, the next time the schedule
update_computed_fields runs, the dtstart
will fast forward to today's date, and
next_run will be computed from that. This will trigger
the job to run again, which is not intended.

If count is set, we just should not fast forward the
rrule and always calculate next_run based on original
dtstart.

Signed-off-by: Seth Foster <fosterbseth@gmail.com>
This commit is contained in:
Seth Foster 2024-12-11 11:14:58 -05:00 committed by GitHub
parent f377b5fdde
commit e605883592
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
2 changed files with 9 additions and 0 deletions

View File

@ -64,6 +64,9 @@ def _fast_forward_rrule(rrule, ref_dt=None):
if rrule._freq not in {dateutil.rrule.HOURLY, dateutil.rrule.MINUTELY}:
return rrule
if rrule._count:
return rrule
if ref_dt is None:
ref_dt = now()

View File

@ -115,6 +115,12 @@ def test_future_date_does_not_fast_forward():
assert new_rrule == rrule
def test_rrule_with_count_does_not_fast_forward():
rrule = dateutil.rrule.rrule(freq=MINUTELY, interval=5, count=1, dtstart=REF_DT)
assert rrule == _fast_forward_rrule(rrule, ref_dt=REF_DT)
@pytest.mark.parametrize(
('freq', 'interval'),
[