Redriving

Redriving takes messages out of an error queue and puts them back on the queue they came from. It runs over AMQP as the connection's account; which operations travel over which protocol is mapped in Queues & messages.

What a redrive does

For each message, Redrive fetches it with basic.get, publishes a copy to the target queue through the default exchange, and acknowledges the original once the broker confirms the copy. A failed publish leaves the original on the error queue. Stream queues cannot be redriven, because basic.get does not apply to streams.

The target comes from the queue name: Redrive strips a trailing _error, so submit-order_error redrives to submit-order. The redrive dialog shows the resolved target and refuses to start while that queue does not exist.

MassTransit names each error queue after the endpoint that failed, so the convention target is the queue the message failed in. When a selected message's fault records a different input queue, the dialog warns before you confirm.

On a queue whose name does not end in _error, nothing resolves and you pick the target yourself. Change target lists the other queues in the vhost, and the copies publish to the queue you pick, wherever the messages came from.

The copy keeps the original body and AMQP properties. Redrive stamps three headers on it (x-redrive-count, x-redrive-source, and x-redrive-at) and by default strips the MT-Fault-* headers MassTransit recorded when the message failed; a switch in the dialog keeps them. Bodies you edit while inspecting messages go out in their edited form when you redrive a selection. An edit must be valid JSON, and a body that was a MassTransit envelope must still parse as one.

Every run lands in the action log with its source, target, count, and outcome, stripped fault headers included. The account needs read on the queue and write on the default exchange; the permission table is in Getting started.

Selecting messages

A redrive starts from a peek snapshot. You can redrive the message you are inspecting on its own, and the checkboxes in the list collect a selection to redrive in one run. Redrive all takes the whole queue: each run moves up to the batch limit from the head, and running it again continues where the last run stopped.

Selections are tracked by token rather than by position. A message's token is its MassTransit message id, or the AMQP message-id property, or a hash of the body and headers when it has neither. The queue keeps moving between peek and redrive, so the run re-reads the queue and matches by token: it moves exactly the messages you picked and reports any it could not find. Two snapshot rows with the same token count as one message; the list flags the duplicates, and the run moves the first match.

Batches and scan depth

Two limits bound every run, redrive and discard alike:

Limit	Default	What it bounds
Batch limit	`100`	Messages moved per run. A selection holds at most this many, and Redrive all stops after this many moves.
Scan depth	`1000`	Messages read while matching. A selected message deeper in the queue than this is reported not found.

Raise the batch limit when emptying a large error queue a hundred messages at a time takes too many runs. Raise the scan depth when a queue runs deeper than 1,000 messages and your selections sit far behind the head. Both are set by environment variable; see Configuration. The dialog shows the numbers that will apply before you confirm.

Scanning a quorum queue on RabbitMQ older than 4.3 spends delivery-limit headroom. Messages the run passes over are requeued, and those brokers count the requeue as a failed delivery; a message at the limit is dropped or dead-lettered when passed over. The dialog repeats this warning when it applies.

When a redrive fails

The run stops at the first message it cannot move. That message is reported with the broker's error, messages moved before it stay moved, and messages read but not matched return to the queue. Selected messages the run never reached are reported failed with a note that the batch stopped first. There is no rollback; the action log records the run as stopped and why.

If the request itself never returns, completed moves stand. Peek again to see the current state of the queue.

Discarding

Discard removes selected messages without publishing them anywhere. The same walk fetches each match with basic.get and acknowledges it; the message is gone, not dead-lettered, and the action log entry is the only trace. The batch limit and scan depth apply, and the account needs read on the queue.

Discard always takes an explicit selection. To drop everything in a queue, use purge instead; see Queues & messages.