RabbitMQ / Basic: protocol resources, routing and ownership / Lesson 3

Publisher confirms and unroutable messages

Track broker acceptance separately from routing and business completion, including uncertain network outcomes.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain the scope of publisher confirms and mandatory returns.
Design bounded tracking for outstanding publications.

A confirm is a broker-side milestone

Publisher confirms tell the publisher about RabbitMQ's acceptance under the destination queue or stream contract. They do not tell it whether a consumer completed a label calculation or sent a notification. Consumer acknowledgments are independent and are not forwarded as publisher confirms. Observe asynchronous confirm outcomes instead of treating a successful client send call as final acceptance. The exact point of confirmation depends on the destination type and persistence behavior. Keep business completion as a separate observable protocol when a caller needs that result, and state explicitly which failure scenarios the acceptance contract covers.

Acceptance can coexist with no destination match

An existing exchange can accept a publication that matches no queue binding. Without appropriate unroutable handling, such a publication can be discarded under the topology rules. With mandatory publishing, an unroutable message is returned to the publisher through the supported return mechanism; a publisher must handle returns as well as confirms. A positive confirm alone is not proof of useful routing. A missing exchange is different and can close the channel with NOT_FOUND. Keep these cases separate in application error handling, and review alternate-exchange behavior when it is part of the intended topology.

Record the publication requirements together

The JSON record names a synthetic exchange, routing key and stable message identity, and says both confirms and mandatory-return handling are required. It is an application design record, not an executable client API configuration. A real client must enable the supported confirm mode, register outcome handlers and bound the number or bytes of pending messages. Waiting synchronously for each individual confirm can reduce throughput, while unlimited asynchronous buffering can exhaust memory. Choose a bounded window and delivery deadline from the application requirement, then validate it in an independently authorized environment rather than copying a universal batch size.

json Synthetic publication outcome contract

{"exchange":"lab.events","routing_key":"parcel.accepted","message_id":"evt-P17-accepted","publisher_confirms":true,"mandatory":true,"handle_returns":true}

Confirms and returns cover different outcomes; these flags are documentation rather than a client constructor.

Retain unconfirmed identity for reconciliation

The offline model begins with three publisher sequence entries and removes two when a supplied multiple-confirm boundary covers them. One original operation remains pending. This illustrates bookkeeping only, not RabbitMQ sequence allocation, nack behavior or client callback ordering. Sequence numbers belong to a channel's confirm context and should map back to stable application identities. After connection loss, unconfirmed publications can have been accepted even though their confirms were not observed. Retrying them can duplicate work, so retain original identity and require duplicate-safe destination handling instead of assuming every pending entry was definitely absent from the broker.

python Offline multiple-confirm bookkeeping

pending = {1: 'evt-a', 2: 'evt-b', 3: 'evt-c'}
confirmed_through = 2
pending = {seq: event_id for seq, event_id in pending.items() if seq > confirmed_through}
assert pending == {3: 'evt-c'}
print(pending[3])

Expected output

evt-c

The supplied boundary clears 1 and 2; this does not emulate broker callbacks or prove delivery.

Make timeout and failure outcomes explicit

A publication policy needs a finite pending window, a deadline and a terminal decision for nacks, returns and channel failure. Logging an error and discarding the original operation silently changes delivery semantics. A timeout can represent uncertainty rather than definite rejection, so reconciliation should use the original business identity. Preserve enough sanitized context to distinguish no route, broker rejection and lost acknowledgment. This course starts no publisher and observes no real confirm. Its model checks a supplied completion boundary while all client/platform requirements remain unexecuted design material with explicit limitations.

Common errors and fixes

A positive confirm is reported as completed business work.

Why it happens: Broker acceptance was confused with consumer completion.
How to fix it: Use a separate business-result acknowledgment or status contract.
Prevent it next time: Name transport and business milestones in metrics.

Confirmed messages disappear because no binding matched.

Why it happens: Unroutable returns or alternate routing were not handled.
How to fix it: Review mandatory handling and intended topology together.
Prevent it next time: Test a deliberate no-route publication in an authorized lab.

Unconfirmed operations are retried with fresh identities.

Why it happens: Lost confirmation was treated as proof of nonacceptance.
How to fix it: Retain original identities and reconcile uncertain outcomes.
Prevent it next time: Bound pending state and document its recovery policy.

Check your understanding

1. Can a mandatory return and a positive publisher confirm refer to the same unroutable publication?

Show worked solution

Yes. They describe different aspects: the broker handled the publication, but routing found no queue under the applicable topology. The publisher must process both channels of evidence and treat the return according to its business policy. A confirm-only success counter would conceal this missing-destination outcome.

2. Why should the pending model retain evt-c rather than replace it with a new identifier after failure?