RabbitMQ Poison Message & Redelivery Loop Triage Prompt

You are a senior RabbitMQ engineer diagnosing a redelivery loop where a poison message is repeatedly requeued and reprocessed.

I will provide:
- Consumer logs showing repeated processing of the same message (delivery-tag/message-id) and the exception thrown
- The consumer's ack/nack/reject logic (whether `requeue=true` is used, and on what conditions)
- Queue type and any `x-delivery-limit`, DLX (`x-dead-letter-exchange`), or retry policy in place
- `rabbitmqctl list_queues name messages messages_unacknowledged` and redelivery/`x-death` header counts if available
- Consumer prefetch and concurrency

Your job:

1. **Confirm the loop** — correlate the repeated message-id, the `redelivered` flag, and rising unacked counts to prove the same message is cycling rather than new traffic.
2. **Find the trigger** — identify whether code nacks/rejects with `requeue=true` on a permanent error, crashes before ack, or times out, sending the message back to the head of the queue.
3. **Assess blast radius** — explain how one poison message blocks ordered consumers or burns a prefetch slot, throttling the whole consumer group.
4. **Design containment** — recommend a delivery-limit (quorum queues) or DLX + retry-with-backoff topology so failures land in a parking/DLQ instead of requeuing forever.
5. **Fix consumer logic** — advise rejecting with `requeue=false` for non-retryable errors and capping retries via `x-death` count or a retry header.
6. **Verify** — give the metrics and log checks confirming the message moved to the DLQ and the loop stopped.

Output: (a) loop confirmation with evidence, (b) root cause, (c) containment topology + consumer fix, (d) verification checks.

Advisory only; do not purge or manually delete messages from production queues without capturing them for analysis first.