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
Originally posted by AryanHamedani February 13, 2024 The ModelEntry class in django-celery-beat includes a logic snippet that resets total_run_count to 0 for one-off tasks after they run once:
# ONE OFF TASK: Disable one off tasks after they've ran once
if self.model.one_off and self.model.enabled \
and self.model.total_run_count > 0:
self.model.enabled = False
self.model.total_run_count = 0 # Reset
self.model.no_changes = False # Mark the model entry as changed
self.model.save()
# Don't recheck
return schedules.schedstate(False, NEVER_CHECK_TIMEOUT)
This behavior raises a discussion point: - Preserving run history:
While disabling the task makes sense, resetting total_run_count loses valuable information about its execution history. Understanding past execution is crucial for debugging, auditing, and future scheduling decisions. - Redundant state update:
Is disabling the task sufficient to prevent future runs? Does the reset of total_run_count add unnecessary complexity? - Alternative solutions:
Are there better ways to handle one-off tasks after they run once, while still maintaining a record of their execution?
I propose this discussion to solicit community input on:
The rationale behind the current behavior.
Potential drawbacks of losing the execution history.
Alternative approaches that balance task disablement with run history preservation.
Feasibility and contributions to addressing this potential improvement.
I believe this discussion can lead to a more intuitive and informative way to manage one-off tasks in django-celery-beat.
The text was updated successfully, but these errors were encountered:
Discussed in #730
Originally posted by AryanHamedani February 13, 2024
The
ModelEntry
class in django-celery-beat includes a logic snippet that resetstotal_run_count
to 0 for one-off tasks after they run once:This behavior raises a discussion point:
- Preserving run history:
While disabling the task makes sense, resetting total_run_count loses valuable information about its execution history. Understanding past execution is crucial for debugging, auditing, and future scheduling decisions.
- Redundant state update:
Is disabling the task sufficient to prevent future runs? Does the reset of total_run_count add unnecessary complexity?
- Alternative solutions:
Are there better ways to handle one-off tasks after they run once, while still maintaining a record of their execution?
I propose this discussion to solicit community input on:
The text was updated successfully, but these errors were encountered: