A GIS export worker pulled a Queue message but processing will exceed the remaining visibility window. What should the consumer do so the message does not return mid-work?
Select an answer to reveal the explanation.
Short Explanation
If work will beat the hide window, update the message to extend invisibility. That is the “update” principle. Bumping the queue-wide default is blunt; per-message update is precise. Functions timeouts are a different clock.
Full Explanation
When a GIS export worker has pulled a Queue message but processing will exceed the remaining visibility window, the consumer should update the message to extend its invisibility for the remaining work. Per-message update is the surgical tool: it keeps the same unit of work hidden without changing the queue-wide default for every other message and without abandoning the message. Raising only the Oracle Functions timeout and ignoring Queue visibility fails because the clocks are independent—Function duration limits do not extend Queue’s hide window, so the message can reappear mid-export to another worker. Deleting the message immediately then recreating it after the export finishes risks loss if the process dies between delete and recreate, and it breaks the normal completion contract. Switching the payload to Events so visibility timeouts no longer apply abandons Queue’s transactional inbox for a different service that does not solve long-running job locking. Exam caveat: update extends invisibility; it does not reset poison-message delivery accounting the way a successful delete would—still aim to finish and delete, and watch delivery count if updates fail. Operational check: log visibility deadlines, call update when remaining work exceeds the window, and verify competing consumers still cannot receive the message until final delete.