An ibis-lagoon worker crashes after dequeue and the order vanishes. Which receive mode should the developer use so unfinished work can reappear?
Select an answer to reveal the explanation.
Short Explanation
Receive-and-delete is a one-way ticket. Use peek-lock: lock, do the work, complete — and if the worker dies, the lock expires and the message comes back.
Full Explanation
Peek-lock is the Service Bus receive mode that protects an ibis-lagoon worker from silent message loss after dequeue. The broker locks the message while the worker processes it; Complete removes it from the entity, while Abandon or lock timeout returns it for another attempt. That at-least-once pattern keeps unfinished orders available after a crash instead of vanishing between receive and business success, which is exactly what receive-and-delete cannot recover from.
Receive-and-delete so the message is removed before processing starts fails because the broker already deleted the message—if the worker dies mid-work, there is nothing left to redeliver and the order is gone. Fire-and-forget HTTP posts with no Service Bus entity fail conceptually: they abandon broker-mediated delivery, locks, redelivery, and dead-lettering. Event Hubs Capture as the only order acknowledgment fails because Capture archives stream data to Blob or Data Lake; it is not a Service Bus receive mode for command completion.
Exam caveat: peek-lock still requires idempotent handlers because a completed business side effect plus a crash before Complete can cause redelivery of the same order. Operational check: receive with peek-lock on a test queue, kill the worker before Complete, wait for lock expiry, and confirm another receiver can obtain the same message and finish it safely.