The Fix
pip install celery==3.1
Based on closed celery/celery issue #4349 · PR/commit linked
@@ -305,6 +305,12 @@ def _limit_task(self, request, bucket, tokens):
return self._schedule_bucket_request(request, bucket, tokens)
+ def _limit_post_eta(self, request, bucket, tokens):
+ self.qos.decrement_eventually()
+ if bucket.contents:
repro
Create a task.
Add the datetime when the task started to run.
Apply a rate limit in minutes to it (i.e. 25/m).
Count the logs appearances of the task per minute (i.e. `cat /var/log/celery.log | grep 2017/10/25/T21:27 | grep -c "task_name"`)
verify
Follow the reproduction steps, confirm the failure, apply the fix, and repeat the same steps to verify the behavior changes.
fix.md
Option A — Upgrade to fixed release\npip install celery==3.1\nWhen NOT to use: This fix should not be applied if task retries are intended to bypass rate limits.\n\n
Why This Fix Works in Production
- Trigger: Tasks were executing at rates exceeding the defined limits, causing potential overload.
- Mechanism: Task retries were not respecting the defined rate limits, leading to excessive task executions
- Why the fix works: Adds a new function to handle task rate limits in conjunction with ETA, ensuring that tasks respect the specified rate limit even when retried. (first fixed release: 3.1).
Production impact:
- If left unfixed, this can cause silent data inconsistencies that propagate (bad cache entries, incorrect downstream decisions).
Why This Breaks in Prod
- Task retries were not respecting the defined rate limits, leading to excessive task executions
- Production symptom (often without a traceback): Tasks were executing at rates exceeding the defined limits, causing potential overload.
Proof / Evidence
- GitHub issue: #4349
- Fix PR: https://github.com/celery/celery/pull/4251
- First fixed release: 3.1
- Reproduced locally: No (not executed)
- Last verified: 2026-02-09
- Confidence: 0.85
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.67
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“Has the same problem with 3.25. @hassek , @SHxKM I believe solution is merged into 4th major release: https://github.com/celery/celery/pull/4251 So upgrade to 4.2 should solve…”
“I would request to try latest release or latest master update and report again”
“@auvipy will do, I have it on my pipeline. On another note, do you know if task retries are bound to rate limits? I believe…”
“may be there is option to set retry limit time explicitely”
Failure Signature (Search String)
- Tasks were executing at rates exceeding the defined limits, causing potential overload.
Copy-friendly signature
signature.txt
Failure Signature
-----------------
Tasks were executing at rates exceeding the defined limits, causing potential overload.
Error Message
Signature-only (no traceback captured)
error.txt
Error Message
-------------
Tasks were executing at rates exceeding the defined limits, causing potential overload.
Minimal Reproduction
- Create a task.
- Add the datetime when the task started to run.
- Apply a rate limit in minutes to it (i.e. 25/m).
- Count the logs appearances of the task per minute (i.e. `cat /var/log/celery.log | grep 2017/10/25/T21:27 | grep -c "task_name"`)
What Broke
Tasks were executing at rates exceeding the defined limits, causing potential overload.
Why It Broke
Task retries were not respecting the defined rate limits, leading to excessive task executions
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
pip install celery==3.1
When NOT to use: This fix should not be applied if task retries are intended to bypass rate limits.
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/4251
First fixed release: 3.1
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- This fix should not be applied if task retries are intended to bypass rate limits.
Verify Fix
verify
Follow the reproduction steps, confirm the failure, apply the fix, and repeat the same steps to verify the behavior changes.
Did This Fix Work in Your Case?
Quick signal helps us prioritize which fixes to verify and improve.
Prevention
- Capture the exact failing error string in logs and tests so you can reproduce via a minimal script.
- Pin production dependencies and upgrade only with a reproducible test that hits the failing path.
Version Compatibility Table
| Version | Status |
|---|---|
| 3.1 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.