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
There is validation while creating CrontabSchedule objects. But such validation allows crontabs that never runs, such as * * 1 31 2, to be created and used within PeriodicTask objects. Having such crontabs while using beat as separate process celery -A [project-name] beat -l info -S django lead to RuntimeError.
I'm running django with celery and have a user newsletter that may be sent monthly, weekly or never. For that purpose, I decided to use 3 crontabs to do the job and the "never" crontab I chose was 31 of february instead of the classical year 3099. Project decisions apart, I believe that allowing the crontab creation while throwing a RuntimeError on that crontab existence is a bug and it led me to waisting way more time than I would have if the create validation already stated the problem.
The system runs on docker containers following cookiecutter-django patterns.
Logs:
[2024-05-07 12:10:10,954: CRITICAL/SpawnProcess-1] beat raised exception <class 'RuntimeError'>: RuntimeError('unable to rollover, time specification is probably invalid')
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/celery/apps/beat.py", line 113, in start_scheduler
service.start()
File "/usr/local/lib/python3.11/site-packages/celery/beat.py", line 643, in start
interval = self.scheduler.tick()
^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/beat.py", line 339, in tick
self.populate_heap()
File "/usr/local/lib/python3.11/site-packages/celery/beat.py", line 313, in populate_heap
is_due, next_call_delay = entry.is_due()
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/django_celery_beat/schedulers.py", line 136, in is_due
return self.schedule.is_due(last_run_at_in_tz)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/django_celery_beat/tzcrontab.py", line 41, in is_due
rem_delta = self.remaining_estimate(last_run_at)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/schedules.py", line 617, in remaining_estimate
return remaining(*self.remaining_delta(last_run_at, ffwd=ffwd))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/schedules.py", line 604, in remaining_delta
delta = self._delta_to_next(last_run_at,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/celery/schedules.py", line 516, in _delta_to_next
roll_over()
File "/usr/local/lib/python3.11/site-packages/celery/schedules.py", line 505, in roll_over
raise RuntimeError('unable to rollover, '
RuntimeError: unable to rollover, time specification is probably invalid
The text was updated successfully, but these errors were encountered:
Summary:
There is validation while creating
CrontabSchedule
objects. But such validation allows crontabs that never runs, such as* * 1 31 2
, to be created and used withinPeriodicTask
objects. Having such crontabs while using beat as separate processcelery -A [project-name] beat -l info -S django
lead toRuntimeError
.Exact steps to reproduce the issue:
Detailed information
I'm running django with celery and have a user newsletter that may be sent monthly, weekly or never. For that purpose, I decided to use 3 crontabs to do the job and the "never" crontab I chose was 31 of february instead of the classical year 3099. Project decisions apart, I believe that allowing the crontab creation while throwing a
RuntimeError
on that crontab existence is a bug and it led me to waisting way more time than I would have if the create validation already stated the problem.The system runs on docker containers following cookiecutter-django patterns.
Logs:
The text was updated successfully, but these errors were encountered: