Rethinking total_run_count reset for one-off tasks in is_due

[AryanHamedani]

Discussed in https://github.com/celery/django-celery-beat/discussions/730

^{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.

[alirafiei75]

i have the same problem with this. total run count is useless in this way.