A utility billing worker crashes after consuming a Queue message but before deleting it. What happens when visibility ends, and what design duty follows?
Select an answer to reveal the explanation.
Short Explanation
Delete is what completes Queue work. If the consumer crashes or never deletes, visibility ends and the message returns—delivery count goes up. Design handlers to be safe if they run twice. Streaming’s “read does not remove” is a different model.
Full Explanation
If a utility billing worker crashes after consuming a Queue message but before deleting it, when visibility ends the message becomes visible again, the delivery count increases, and another consumer (or a restarted worker) may receive it. Handlers must therefore tolerate at-least-once redelivery: make processing idempotent so duplicate runs do not double-bill or corrupt municipal records. Delete remains the completion signal; consume alone is not permanent removal. Claiming the message is gone forever because Queue treats consume as permanent removal like a destructive read is false—the hide is temporary until delete or expiry. Applying Streaming semantics where read never removes and delete is ignored even if called later mixes products: Queue delete is meaningful and required for completion. Expecting Events to automatically dead-letter the message on worker crash without Queue involvement invents cross-service behavior; dead-lettering is a Queue feature driven by delivery attempts on that queue. Exam caveat: idempotency keys, conditional writes, or “already processed” checks in the billing datastore are exam- and production-critical once you accept at-least-once delivery. Operational check: simulate a crash after consume without delete, wait for visibility to elapse, confirm redelivery and incremented delivery count, then prove the handler’s idempotent path does not apply the charge twice.