New: Cookbooks and AI ExplanationsStep-by-Step recipes to solve problems connected to Roadmaps and Cheat Sheets. Need more details? Use AI buttons for structured and simple explanations with concrete examples throughout the whole platform.Take a look
My worker just picked up a job when I killed it, and the job is gone: no error, no retry, nothing.
What you'll have at the end
A queue and its messages that both survive a killed worker and a restarted broker, with nothing silently dropped
You need
A worker process that already pulls jobs off a queue one at a time and does real, several-second work on each one, so a kill signal landing mid-job is a live, everyday risk.
Not covered
Making a job safe to run twice when a crash lands the acknowledgment and the redelivery on top of each other; that only matters once messages stop disappearing outright, and it is a separate problem.
Leans on
Make your queue consumer idempotent
redelivery after a crash can hand the same job to two workers if the first one finishes right as the connection drops; making repeat processing harmless is the next problem once jobs stop disappearing outright.
Prove a message reached the broker with a publisher confirm
covers the publish side of the same worry, confirming the broker actually has the job before your producer moves on, instead of trusting a bare publish call.
Move a slow task off the request and into a background queue
for getting the slow work off the request and onto a queue in the first place, before this recipe's concern about surviving a crash while processing it applies.
Checked 19 Aug 2026
Part of the Message Queues cookbook