The Fix
pip install celery==5.5.0
Based on closed celery/celery issue #9596 · 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.
@@ -602,8 +602,8 @@ def on_failure(self, exc_info, send_failed_event=True, return_ok=False):
if self.task.acks_late:
reject = (
- self.task.reject_on_worker_lost and
- is_worker_lost
+ (self.task.reject_on_worker_lost and is_worker_lost)
repro.py
software -> celery:5.4.0 (opalescent) kombu:5.4.2 py:3.11.9
billiard:4.2.1 py-amqp:5.3.1
platform -> system:Linux arch:64bit, ELF
kernel version:6.10.14-linuxkit imp:CPython
loader -> celery.loaders.app.AppLoader
settings -> transport:amqp results:disabled
deprecated_settings: None
worker_disable_rate_limits: True
event_queue_expires: 30
event_queue_ttl: 5
worker_hijack_root_logger: False
worker_send_task_events: False
task_acks_late: True
task_acks_on_failure_or_timeout: False
task_ignore_result: True
task_reject_on_worker_lost: True
worker_cancel_long_running_tasks_on_connection_loss: True
broker_heartbeat: 120
task_queues: [<unbound Queue a -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue b -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue c -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue d -> <unbound Exchange tasks(direct)> -> tasks>]</b></summary>
<p>
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.5.0\nWhen NOT to use: Do not apply this fix if task_acks_on_failure_or_timeout should remain True for specific tasks.\n\n
Why This Fix Works in Production
- Trigger: Task acks on Hard Timeout when `task_acks_on_failure_or_timeout` is `False`
- Mechanism: The task does not reject when exceeding the Hard Timeout limit with task_acks_on_failure_or_timeout set to False
- Why the fix works: Ensures that surpassing the Hard Timeout limit when `task_acks_on_failure_or_timeout` is False rejects the task, addressing issue #9596. (first fixed release: 5.5.0).
Production impact:
- If left unfixed, the same config can fail only in production (env differences), causing startup failures or partial feature outages.
Why This Breaks in Prod
- The task does not reject when exceeding the Hard Timeout limit with task_acks_on_failure_or_timeout set to False
- Production symptom (often without a traceback): Task acks on Hard Timeout when `task_acks_on_failure_or_timeout` is `False`
Proof / Evidence
- GitHub issue: #9596
- Fix PR: https://github.com/celery/celery/pull/9626
- First fixed release: 5.5.0
- Reproduced locally: No (not executed)
- Last verified: 2026-02-09
- Confidence: 0.75
- Did this fix it?: Yes (upstream fix exists)
- Own content ratio: 0.47
Discussion
High-signal excerpts from the issue thread (symptoms, repros, edge-cases).
“Thank you for the report. I see you already have some progress here: https://github.com/celery/celery/discussions/9597 Would you like to contribute a fix in a PR? I’d…”
“> Would you like to contribute a fix in a PR? I’d be happy to review it. Just make sure to add the necessary tests.…”
Failure Signature (Search String)
- Task acks on Hard Timeout when `task_acks_on_failure_or_timeout` is `False`
- - [x] I have included all related issues and possible duplicate issues
Copy-friendly signature
signature.txt
Failure Signature
-----------------
Task acks on Hard Timeout when `task_acks_on_failure_or_timeout` is `False`
- [x] I have included all related issues and possible duplicate issues
Error Message
Signature-only (no traceback captured)
error.txt
Error Message
-------------
Task acks on Hard Timeout when `task_acks_on_failure_or_timeout` is `False`
- [x] I have included all related issues and possible duplicate issues
Minimal Reproduction
repro.py
software -> celery:5.4.0 (opalescent) kombu:5.4.2 py:3.11.9
billiard:4.2.1 py-amqp:5.3.1
platform -> system:Linux arch:64bit, ELF
kernel version:6.10.14-linuxkit imp:CPython
loader -> celery.loaders.app.AppLoader
settings -> transport:amqp results:disabled
deprecated_settings: None
worker_disable_rate_limits: True
event_queue_expires: 30
event_queue_ttl: 5
worker_hijack_root_logger: False
worker_send_task_events: False
task_acks_late: True
task_acks_on_failure_or_timeout: False
task_ignore_result: True
task_reject_on_worker_lost: True
worker_cancel_long_running_tasks_on_connection_loss: True
broker_heartbeat: 120
task_queues: [<unbound Queue a -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue b -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue c -> <unbound Exchange tasks(direct)> -> tasks>,
<unbound Queue d -> <unbound Exchange tasks(direct)> -> tasks>]</b></summary>
<p>
What Broke
Tasks may incorrectly acknowledge completion, leading to potential data loss or unprocessed tasks.
Why It Broke
The task does not reject when exceeding the Hard Timeout limit with task_acks_on_failure_or_timeout set to False
Fix Options (Details)
Option A — Upgrade to fixed release Safe default (recommended)
pip install celery==5.5.0
When NOT to use: Do not apply this fix if task_acks_on_failure_or_timeout should remain True for specific tasks.
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/9626
First fixed release: 5.5.0
Last verified: 2026-02-09. Validate in your environment.
When NOT to Use This Fix
- Do not apply this fix if task_acks_on_failure_or_timeout should remain True for specific tasks.
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
- 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 |
|---|---|
| 5.5.0 | Fixed |
Related Issues
No related fixes found.
Sources
We don’t republish the full GitHub discussion text. Use the links above for context.