Publisher Confirm Timeout Behavior in RabbitMQ Client Libraries

Goal

Establish a reliable approach for dealing with publisher confirm timeouts in RabbitMQ client libraries that avoids both duplicate message delivery and message loss.

Constraints and Uncertainty

The AMQP 0‑9‑1 specification does not define what a client should do when a confirm timeout occurs, leaving the decision to each library. Some libraries raise an exception and treat the publish as failed, while others keep the confirm pending and allow the application to retry. Because the timeout is purely client‑side, a broker may later send an Ack or Nack after the application has already acted, which can cause duplicates if the message is resent or loss if a Nack is interpreted as a definitive failure. Network latency spikes or broker load can trigger timeouts even when the message has already been persisted.

• Should the client automatically republish the message after a confirm timeout, assuming the broker may not have persisted it?
• Should the client treat a timeout as a transient error and leave the confirm pending for the application to decide on a retry?
• Should the client consider the message as possibly persisted and rely on consumer‑side idempotency instead of retrying?