A confirmed message produces no business result

Understand the likely causes

• The message may have been unroutable, expired or overflowed after acceptance, waited without a healthy consumer, or been acknowledged before its required effect. An application may also have mislabeled local send completion as a broker confirm.

Verify exactly which acceptance was observed

Collect the original operation identifier, vhost, exchange, routing key and sanitized publisher outcome evidence. Confirm that the application observed an actual publisher confirm rather than merely returning from a local send method. Correlate returns, nacks and channel closure with the same publication context. An existing exchange can positively confirm an unroutable publication while mandatory handling reports no destination; the two outcomes are not contradictory. A missing exchange is a separate channel-error path. Preserve the original identity before retrying, because a missing business result does not prove the first operation was never accepted.

Trace the intended queue and its lifecycle

Compare the declared routing contract with existing topology evidence from the incident interval. Check the selected vhost, binding key and expected destination rather than searching only a short queue name. Then review message TTL, ready-length overflow, dead-letter routes and temporary queue ownership. A queue deleted with its declaring connection has different recovery meaning from a durable queue whose worker is offline. Dead-lettering adds another publication and can fail under its safety mode. A definitions file or a current empty queue does not alone explain where an earlier message went; keep timeline and policy versions with the evidence.

Locate the consumer responsibility boundary

Use operation identity to compare delivery, handler start, destination acceptance and acknowledgment. Ready backlog suggests different questions from a delivery held unacknowledged by a worker. A consumer can acknowledge immediately and later fail its remote label call, leaving low queue depth without a valid result. Conversely, it can complete the effect and lose its acknowledgment, creating replay risk rather than definite loss. Do not clear queues or force acknowledgments to improve a graph. The local fixture distinguishes broker acceptance from business completion only; it does not query a queue or establish that a real message was lost.

state = {'broker_confirmed': True, 'business_complete': False}
assert state['broker_confirmed'] and not state['business_complete']
print('broker-accepted; business-pending')

broker-accepted; business-pending

Recover the original occurrence with evidence

Choose the correction supported by the identified boundary: fix routing, repair a supported lifecycle policy, restore consumer progress or reconcile a destination effect. Retry or replay with the original operation identity and the destination’s duplicate-safe contract. If expiry or intentional overflow removed required work, document the coverage gap and supported source for reconstruction. This guide executes no replay, binding change or service operation. After a separately authorized fix, acceptance should show the synthetic operation reaches either its required result or an explicit terminal outcome, with both publisher and consumer milestones accounted for.

Keep it from recurring

• Keep routing, retention, overflow and business-completion contracts together. Record stable operation identity at every milestone, and alert on missing accepted results rather than inferring end-to-end success from publisher confirms.