A Function repeatedly fails on a corrupt permit PDF from the queue. What poison-message strategy should operators follow?
Select an answer to reveal the explanation.
Short Explanation
Poison handling is knowing when to stop chewing the same bad permit PDF and drop it in the problem bin—bounded retries, then dead-letter, so the rest of the line keeps moving.
Full Explanation
When a Function repeatedly fails on a corrupt permit PDF from the queue, operators need bounded retries and a poison path—not infinite loops. After max delivery attempts, move the message to a Service Bus dead-letter queue (or Functions poison queue pattern for storage queues), alert on-call or municipal AI ops, and keep the main queue draining healthy work. Corrupt inputs are expected occasionally; the strategy is isolate, investigate, and replay only after a fix.
Retrying infinitely forever so one bad PDF stalls all later permit jobs fails availability: delivery count climbs, locks churn, and throughput collapses. Crashing the entire Function host process on the first failure amplifies a single poison payload into a broader outage. Acknowledging success without logging so the corrupt PDF appears processed falsifies municipal processing state and loses the only chance to remediate.
Exam caveat: distinguish transient faults (retry) from poison payloads (dead-letter). Application Insights should capture the MessageId and blob URI. Operational check: enqueue a known corrupt PDF, confirm retries stop at the bound, confirm DLQ/poison path receives it, confirm subsequent good messages still process, and verify an alert fired for operator follow-up.