Stop a stuck consumer from holding work forever
A consumer that can hold a message forever, bounded so a hung handler returns the work to the queue.
The ticket
Add a processing timeout and a visibility window to a consumer that can hang.
Acceptance criteria
- Processing has an explicit timeout
- The visibility window is longer than the timeout
- A hung handler releases the message rather than holding it
- A test forces a hang and asserts the message becomes available again
What lands as proof
A forced-hang test showing the message returns to the queue rather than disappearing into a stuck worker.
Why teams defer it
- A hang looks like slowness rather than failure, so it gets attributed to load.
- Setting the visibility window wrongly causes duplicate processing, which makes people cautious about touching it.
Questions
- What does the agent actually change?
- The ticket is scoped to one outcome: add a processing timeout and a visibility window to a consumer that can hang. Work that serves that outcome is in scope, and anything outside it is left for a separate ticket, so the pull request stays reviewable.
- How do I know the work is done?
- The pull request carries the evidence, not only the diff. Here that means a hung message returns to the queue instead of stalling the worker, so a reviewer can confirm the result without reproducing the work locally.
- How much oversight does this need?
- The run stops once the plan is written. Somebody reads the approach and approves it before any code exists, which is the cheapest moment to redirect the work.