Let's say you have setup RabbitMQ with a way of reprocessing messages. For example, this could be done by reprocessing messages in a dead letter queue. But let's first look at how a message typically gets transmitted from a producer to a consumer. Typically, the producer puts the message onto an exchange with a routing key. The routing key is then used to determine what queue the message should be routed to, the messages gets onto the queue, and the consumer gets the message from the queue.

In this scenario, when the message is routed to the queue, the redelivered value will be set to false. This can be seen using the RabbitMQ REST API. In this example, the messages in foo.queue in the default %2f (forward slash) virtual host will be returned.

curl 
--request POST 
--user john.doe:itsasecret 
--data '{"count":10,"ackmode":"ack_requeue_true","encoding":"auto","truncate":50000}'
--url http://server001:15671/api/queues/%2f/foo.queue/get

The output should look something like this. Notice that redelivered is false.

[
 {
  "payload_bytes": 6
  "redelivered": false
  "exchange": "foo.exchange"
  "routing_key": "foo.key"
  "message_count": 1
  "properties":{"timestamp":1622715703
  "delivery_mode": 2
  "headers":{"timestamp_in_ms":1622715703577}}
  "payload": "Hello World"
  "payload_encoding": "string"
 }
]

Let's say you have the following design, where messages are moved from the original queue (foo.queue) to a dead letter queue, and then back to the original queue.

In this scenario, when the message gets moved back to the original queue, the redelivered value will be true. This can be a hint to a consumer that they may have already seen the message.

[
 {
  "payload_bytes": 6
  "redelivered": true
  "exchange": "foo.exchange"
  "routing_key": "foo.key"
  "message_count": 1
  "properties":{"timestamp":1622715703
  "delivery_mode": 2
  "headers":{"timestamp_in_ms":1622715703577}}
  "payload": "Hello World"
  "payload_encoding": "string"
 }
]