A tamarisk-wash Function processes a Storage queue message and returns, then the same job runs again. What must happen after success?
Select an answer to reveal the explanation.
Short Explanation
Processing is not the same as deleting. After success, delete the message — or let a successful Functions queue binding completion do it — or visibility timeout will hand it out again.
Full Explanation
Storage queues deliver at-least-once semantics: after a tamarisk-wash Function processes a message, the message must be deleted—or completed successfully via the Functions queue binding—or visibility timeout will make it visible again and another invocation will rerun the job. Successful processing without deletion is therefore incomplete work from the broker's point of view.
Leaving the message forever because Storage queues auto-complete on any HTTP 200 from any app fails—there is no such global auto-complete based on unrelated HTTP successes. Converting the queue into Event Hubs so messages self-delete fails conceptually and operationally; Event Hubs is a different service with log retention, not Storage queue completion. Disabling visibility timeout so duplicates become impossible fails because visibility is the in-flight protection; removing it increases contention rather than ensuring exactly-once completion.
Exam caveat: a function that returns success after a partial side effect can delete the message and lose the chance to retry—make success mean fully committed work. Operational check: process a test message and confirm it disappears from the queue only after delete/complete; force a failure path and confirm it reappears after visibility timeout.