A poison message repeatedly crashes or fails processing. With at-least-once delivery, leaving it in the queue can create an endless restart loop: read, fail, restart, and repeat. section 8.2.3
Protect consumption with failure monitoring, such as a try-catch around processing. After repeated failures for the same message, remove it from the main queue and preserve it for inspection. section 8.2.3
Use these safeguards:
- Move poison messages to another persistent queue, commonly called a dead letter queue, so the payload and underlying bug can be investigated. section 8.2.3
- Prepare or validate messages before enqueueing them so one malformed item does not disrupt an entire operation. section 8.2.3
- Account for poison messages when choosing persistent-queue delivery semantics, especially at-least-once delivery. section 8.3

