Celery celery.schedules.crontab is

The Fix

pip install celery==5.3.0b2

Based on closed celery/celery issue #4806 · PR/commit linked

Production note: This usually shows up under retries/timeouts. Treat it as a side-effect risk until you can verify behavior with a canary + real traffic.

Jump to Verify Open PR/Commit

@@ -291,3 +291,4 @@ Tizian Seehaus, 2022/02/09
 JoonHwan Kim, 2022/08/01
 Kaustav Banerjee, 2022/11/10
+Austin Snoeyink 2022/12/06
diff --git a/celery/app/defaults.py b/celery/app/defaults.py
index ce8d0ae1a90..65731e614c0 100644

repro.py

@pytest.mark.skip("broken - pytzcrontab goes into an infinite loop here")
    def test_invalid_specification(self):
        # *** WARNING ***
        # This test triggers an infinite loop in case of a regression
        with pytest.raises(RuntimeError):
            self.next_ocurrance(
                self.pytzcrontab(day_of_month=31, month_of_year=4),
                datetime_utc(2010, 1, 28, 14, 30, 15),
            )

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

fix.md

Option A — Upgrade to fixed release\npip install celery==5.3.0b2\nWhen NOT to use: Do not use this fix if you require the previous scheduling accuracy.\n\n

Why This Fix Works in Production

Trigger: Please apply this patch to celery master branch, remove `@skip.todo` from the first new test, run unit tests, observe the first of these added unit tests fails:
Why the fix works: the upstream fix ships in 5.3.0b2.

Production impact:

If left unfixed, this can cause silent data inconsistencies that propagate (bad cache entries, incorrect downstream decisions).

Why This Breaks in Prod

Production symptom (often without a traceback): Please apply this patch to celery master branch, remove `@skip.todo` from the first new test, run unit tests, observe the first of these added unit tests fails:

Proof / Evidence

GitHub issue: #4806
Fix PR: https://github.com/celery/celery/pull/7945
First fixed release: 5.3.0b2
Reproduced locally: No (not executed)
Last verified: 2026-02-09
Confidence: 0.60
Did this fix it?: Yes (upstream fix exists)
Own content ratio: 0.46

Discussion

High-signal excerpts from the issue thread (symptoms, repros, edge-cases).

Jump to Sources Open on GitHub

“I am in the process of rewriting the celery.schedules.crontab logic to fix this cleanly, if i can get the green light from my client to…”

@fcostin · 2018-06-09 · source

“@fcostin did you ever complete your crontab rewrite and/or (not) get permission to release?”

@fdemmer · 2019-05-02 · source

“@fdemmer - One crude way to fix this is to simply revert the old change that introduced this issue: https://github.com/celery/celery/commit/4ed89ec49582b540149cf06047f091ebd20fb300 , in particular the parts…”

@fcostin · 2019-05-02 · confirmation · source

“This issue is fairly old is there a fix or a work around for this? I see the gist above but I'd rather not have…”

@minsis · 2020-12-07 · source

Failure Signature (Search String)

Please apply this patch to celery master branch, remove `@skip.todo` from the first new test, run unit tests, observe the first of these added unit tests fails:
assert not due

Copy-friendly signature

signature.txt

Failure Signature
-----------------
Please apply this patch to celery master branch, remove `@skip.todo` from the first new test, run unit tests, observe the first of these added unit tests fails:
assert not due

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
Please apply this patch to celery master branch, remove `@skip.todo` from the first new test, run unit tests, observe the first of these added unit tests fails:
assert not due

Minimal Reproduction

repro.py

@pytest.mark.skip("broken - pytzcrontab goes into an infinite loop here")
    def test_invalid_specification(self):
        # *** WARNING ***
        # This test triggers an infinite loop in case of a regression
        with pytest.raises(RuntimeError):
            self.next_ocurrance(
                self.pytzcrontab(day_of_month=31, month_of_year=4),
                datetime_utc(2010, 1, 28, 14, 30, 15),
            )

What Broke

Tasks are triggered unexpectedly, causing duplicate ETL imports.

Fix Options (Details)

Option A — Upgrade to fixed release Safe default (recommended)

pip install celery==5.3.0b2

When NOT to use: Do not use this fix if you require the previous scheduling accuracy.

Use when you can deploy the upstream fix. It is usually lower-risk than long-lived workarounds.

Fix reference: https://github.com/celery/celery/pull/7945

First fixed release: 5.3.0b2

Last verified: 2026-02-09. Validate in your environment.

When NOT to Use This Fix

Do not use this fix if you require the previous scheduling accuracy.

Verify Fix

verify

Re-run the minimal reproduction on your broken version, then apply the fix and re-run.

Did This Fix Work in Your Case?

Quick signal helps us prioritize which fixes to verify and improve.

Prevention

Track RSS + object counts after deployments; alert on monotonic growth and GC pressure.
Add a long-running test that repeats the failing call path and asserts stable memory.

Version Compatibility Table

Version	Status
5.3.0b2	Fixed

Related Issues

No related fixes found.

Cluster: celery:data-consistency Celery hub Celery best practices All hubs All clusters

Related clusters: Configuration error Duplicates Duplicate processing

Sources

We don’t republish the full GitHub discussion text. Use the links above for context.

Celery celery.schedules.crontab is_due logic can trigger periodic celery beat tasks at arbitrary (Fix)