Celery confirm_publish defaults to False and insufficiently

The Fix

pip install celery==5.6.1

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

Production note: Most teams hit this during upgrades or environment changes. Roll out with a canary and smoke critical endpoints (health, OpenAPI/docs) before 100%.

Open PR/Commit

@@ -460,6 +460,13 @@ You can handle this error too:
     ...     logger.exception('Sending task raised: %r', exc)
 
+.. note::
+
+    With RabbitMQ, these errors only indicate the broker is unreachable.

fix.md

Option A — Upgrade to fixed release\npip install celery==5.6.1\nWhen NOT to use: Do not enable `confirm_publish` if immediate task execution without confirmation is required.\n\n

Why This Fix Works in Production

Trigger: None of this is documented. The only example given for `BROKER_TRANSPORT_OPTIONS` is `broker_transport_options = {'visibility_timeout': 18000} # 5 hours`. And…
Mechanism: The default value of `confirm_publish` is False, leading to silent message loss under stress conditions
Why the fix works: Document the `confirm_publish` broker transport option for RabbitMQ to prevent silent message loss when the broker hits resource limits. (first fixed release: 5.6.1).

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 default value of `confirm_publish` is False, leading to silent message loss under stress conditions
Production symptom (often without a traceback): None of this is documented. The only example given for `BROKER_TRANSPORT_OPTIONS` is `broker_transport_options = {'visibility_timeout': 18000} # 5 hours`. And that too, is nowhere near the documentation for `apply_async()`.

Proof / Evidence

GitHub issue: #5410
Fix PR: https://github.com/celery/celery/pull/10016
First fixed release: 5.6.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.71

Discussion

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

Jump to Sources Open on GitHub

“Ran into this recently and was really shocked this was the default. I am going to make time to submit a PR to update the…”

@jseadragon · 2023-07-14 · source

“Agree. I think it is critical for at-least-once delivery.”

@michael-wilg-8 · 2019-06-11 · source

“Would love to see a PR for the docs improvement”

@auvipy · 2021-02-17 · source

“I read a lot of pain in this issue, the same pain I'm experiencing since a week. Thanks @arnonmoscona, you solved my issue. It's a…”

@pdonadeo · 2021-06-10 · source

Failure Signature (Search String)

None of this is documented. The only example given for `BROKER_TRANSPORT_OPTIONS` is `broker_transport_options = {'visibility_timeout': 18000} # 5 hours`. And that too, is
Is there an accompanying timeout or confirm_timeout ? Can confirm_publish infinitely hang?

Copy-friendly signature

signature.txt

Failure Signature
-----------------
None of this is documented. The only example given for `BROKER_TRANSPORT_OPTIONS` is `broker_transport_options = {'visibility_timeout': 18000}  # 5 hours`. And that too, is nowhere near the documentation for `apply_async()`.
Is there an accompanying timeout or confirm_timeout ? Can confirm_publish infinitely hang?

Error Message

Signature-only (no traceback captured)

error.txt

Error Message
-------------
None of this is documented. The only example given for `BROKER_TRANSPORT_OPTIONS` is `broker_transport_options = {'visibility_timeout': 18000}  # 5 hours`. And that too, is nowhere near the documentation for `apply_async()`.
Is there an accompanying timeout or confirm_timeout ? Can confirm_publish infinitely hang?

What Broke

Messages can be silently dropped when RabbitMQ hits resource limits, causing task failures without errors.

Why It Broke

The default value of `confirm_publish` is False, leading to silent message loss under stress conditions

Fix Options (Details)

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

pip install celery==5.6.1

When NOT to use: Do not enable `confirm_publish` if immediate task execution without confirmation is required.

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/10016

First fixed release: 5.6.1

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

When NOT to Use This Fix

Do not enable `confirm_publish` if immediate task execution without confirmation is required.

Did This Fix Work in Your Case?

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

Prevention

Make timeouts explicit and test them (unit + integration) to avoid silent behavior changes.
Instrument retries (attempt count + reason) and alert on spikes to catch dependency slowdowns.

Version Compatibility Table

Version	Status
5.6.1	Fixed

Related Issues

No related fixes found.

Cluster: celery:configuration-error Celery hub Celery best practices All hubs All clusters

Related clusters: Data consistency Duplicates Duplicate processing

Sources

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

Celery confirm_publish defaults to False and insufficiently documented (Fix)