Two worker pods poll the same municipal Queue. What does the visibility timeout provide after one consumer receives a message?
Select an answer to reveal the explanation.
Short Explanation
Visibility timeout is a short processing lock: after receive, the message is hidden from others so two workers do not double-handle it. It is not retention, not a Streaming offset, and not an Events filter.
Full Explanation
When two worker pods poll the same municipal Queue, visibility timeout after one consumer receives a message provides a temporary exclusive hide: other consumers do not see that in-flight message until the timeout ends or the message is deleted. That short processing lock prevents double-handling while still allowing redelivery if the consumer crashes without deleting. A Streaming offset commit that permanently removes the message from all consumers misapplies Streaming semantics—Queue visibility is not an offset commit and does not permanently remove work until delete. An Events filter expression evaluated against the message body confuses Events rule matching with Queue’s receive-side hide window. Equating visibility with the queue’s maximum retention period is wrong: retention bounds how long undeleted messages may exist; visibility bounds how long a received message stays hidden during processing. Exam caveat: setting visibility too short relative to real processing time causes duplicate work; setting it unnecessarily long delays redelivery after crashes—tune with the update API for outliers rather than only the queue default. Operational check: with two consumers, receive a message on pod A, confirm pod B cannot get the same message during the window, then either delete on A or let the window expire and confirm B can receive it again.