A sage-flat worker dequeues a resize job and another worker immediately grabs the same message. What Queue Storage behavior should the developer rely on to hide in-flight work?
Select an answer to reveal the explanation.
Short Explanation
Storage queues do not speak peek-lock. On dequeue, visibility timeout hides the message; finish and delete it, or it pops back when the timeout expires.
Full Explanation
Azure Queue Storage does not speak Service Bus peek-lock. After a sage-flat worker dequeues a resize job, visibility timeout hides that message from other workers until the timeout expires or the message is deleted. If processing finishes in time, delete the message; if the worker dies, the message reappears automatically when visibility returns—providing the in-flight lock analog for Storage queues and preventing two workers from grabbing the same job immediately.
Service Bus peek-lock APIs pointed at the storage queue URL fail because those APIs target Service Bus entities, not storage-account queues, and will not correctly lock Storage queue messages. Event Grid delivery retries as the Storage queue lock fail conceptually: Event Grid retries push delivery to event handlers; they do not implement Storage queue invisibility. Cosmos DB TTL on the queue message body fails because TTL expires Cosmos documents; it is not the Storage queue mechanism that hides in-flight work.
Exam caveat: if processing can exceed the visibility timeout, renew or update visibility (or choose a longer timeout)—otherwise a second worker may grab a still-running job and duplicate side effects. Operational check: dequeue with a short visibility window, attempt a second receive of the same message while it is hidden (should not succeed), then either delete on success or wait and confirm reappearance after timeout.