RabbitMqOptions

pub struct RabbitMqBackend;

impl RabbitMqBackend {
    pub async fn connect(uri: &str) -> Result<Self>;
    pub async fn with_options(uri: &str, options: RabbitMqOptions) -> Result<Self>;
    pub fn options(&self) -> &RabbitMqOptions;
    pub fn dead_queue_name(&self, queue: &str) -> String;
    pub fn deferred_queue_name(&self, queue: &str, ttl_ms: u32) -> String;
}

connect(uri) is with_options(uri, RabbitMqOptions::default()).

The two name methods apply this backend’s suffixes, which is the correct way for tooling to work out what a queue’s companions are called.

Fields

Field	Type	Default
`connection_properties`	`lapin::ConnectionProperties`	`ConnectionProperties::default()`
`dead_suffix`	`String`	`".dead"`
`declare_dead_letter_queues`	`bool`	`true`
`deferred_suffix`	`String`	`".deferred"`
`retry_granularity`	`Duration`	`1s`
`deferred_granularity`	`Duration`	`1s`

Every field has a matching builder that takes and returns self, and all of them are #[must_use]:

let options = RabbitMqOptions::default()
    .dead_suffix("-dlq")
    .declare_dead_letter_queues(true)
    .deferred_suffix(".deferred")
    .retry_granularity(Duration::from_secs(10))
    .deferred_granularity(Duration::from_secs(1));

let backend = RabbitMqBackend::with_options(&url, options).await?;

connection_properties

Passed straight to lapin. Use it to set the client-provided connection name, which is what the management UI shows in its Connections tab:

use lapin::ConnectionProperties;

let props = ConnectionProperties::default()
    .with_connection_name("email-worker-3".into());

RabbitMqOptions::default().connection_properties(props)

lapin is re-exported as queuey::rabbitmq::lapin, so you never need to add it to your own Cargo.toml to do this.

declare_dead_letter_queues

true declares q.dead alongside every work queue, and dead-lettering publishes the envelope there with x-death-reason, x-original-queue and x-attempts.

false changes the mechanism, not just the declaration. Nothing is published. The original message is rejected with requeue = false, so the broker’s own x-dead-letter-exchange policy on q applies, or the message is dropped if there is none. The reason is logged at WARN. Malformed bodies take the same path.

Set it to false only when your infrastructure already manages dead-lettering with a policy.

The granularities

Delays are rounded up to a granularity, and each distinct rounded delay gets its own hold queue.

Option	Applies to	Default
`retry_granularity`	`Delivery::retry` (backoff) and `Producer::enqueue_after`	`1s`
`deferred_granularity`	`Delivery::defer` and `Producer::defer`	`1s`

They are separate because a backoff is a heuristic and tolerates coarse rounding, while a Retry-After is a contract.

retry_granularity is the knob that bounds hold-queue count. Exponential backoff with jitter produces a different delay on every retry, so with a policy capped at five minutes, 1s allows up to 300 hold queues on one work queue and 10s up to 30.

Rounding is always up, so raising a granularity makes things later, never earlier. A zero or sub-millisecond value is clamped to 1 ms rather than rejected.

Names this produces

Method	Example
`dead_queue_name("myapp.emails")`	`myapp.emails.dead`
`deferred_queue_name("myapp.emails", 30000)`	`myapp.emails.deferred.30000`

Limits

A delay may not exceed about 24.8 days, half of RabbitMQ’s maximum TTL, which is what keeps x-expires above the TTL. Longer delays are refused.

Hold-queue x-expires is fixed at 2 * ttl_ms and is deliberately not configurable: hold-queue arguments must be a pure function of the queue name so that every process declares them identically. The 0.1 option deferred_queue_grace was removed for this reason, along with retry_suffix. See Upgrading to 0.2.