It ran twice — or not at all
The queue is empty, which looks exactly like the work being done. Or the side effects happened twice and the ledger records once.
Curated by Code Recycle Editorial
- 1
A worker was killed mid-task. With acks_late=True it ran twice. With Celery's default it vanished, and a restarted worker never saw it again.
Why it's here: Measured: acks_late=True ran the task twice. Celery's default made it vanish.
- 2
A job added with attempts:1 ran on two workers. One completion fired, no failure fired, and the only trace was on a channel nobody subscribes to.
Why it's here: attempts:1 ran on two workers. One completion, no failure, no trace anyone reads.
- 3
Every mainstream queue is at-least-once. Almost every consumer is written as though it were exactly-once. Nothing throws.
Why it's here: Every mainstream queue is at-least-once. Almost every consumer assumes otherwise.
- 4
A key containing a timestamp never matches on retry. It protects nothing while appearing to.
Why it's here: A key containing a timestamp never matches on retry. It protects nothing.
- 5
An order gets fulfilled twice, or a paid order never gets fulfilled at all. Both, prevented.
Why it's here: An order fulfilled twice, or a paid order never fulfilled at all.
- 6
Retries are added to improve reliability and are the standard way to turn a partial outage into a full one.
Why it's here: Retries are the standard way to turn a partial outage into a full one.
- 7
A retry loop that reads the wrong field from a batch result re-sends work that already succeeded, or drops a failure forever. The JSON looks fine either way.
Why it's here: Re-sends work that already succeeded, or drops a failure forever.