hardScenarioConceptDesignMidSeniorStaff
A worker picks up the job you queued and cannot find the row it was told about. What went wrong?
5 min readUpdated 2026-08-15
Answer
Short answer
The job was enqueued inside an open transaction, so the row was invisible to the worker's connection until commit, and a fast worker won the race.on_commit so it fires after the outermost atomic block commits, and never if it rolls back.
Was this answer helpful?
Likely follow-ups
- What does atomic(durable=True) assert, and when would you want it?
- Why does select_for_update raise outside a transaction rather than silently doing nothing?
- How do you test code whose side effect only fires on commit?
- Where does ATOMIC_REQUESTS put the transaction boundary, and what does that make expensive?
Related questions
- A method with REQUIRES_NEW was meant to save an audit row even when the main transaction fails. When does it work, and when does it deadlock?hardAlso on transactions5 min
- Two doctors can go off call only if at least one remains. Both check the rule at the same moment, both see two doctors on call, and both go off call. What isolation problem is this, and what actually fixes it?hardAlso on transactions6 min
- You are getting a handful of deadlock errors an hour under load. How do you find the cause, and how do you stop them?hardAlso on transactions7 min
- Walk me through the transaction isolation levels and which anomalies each one permits.hardAlso on transactions6 min