"Works on my machine" is usually a claim about concurrency, not about dependencies.
Locally you run one process and one worker, a single request at a time. Every race in the code resolves correctly by accident, because there is nothing to race against. Production runs that same code behind a worker pool, and the accident stops happening.
The mechanics are almost always check-then-write. Your handler reads whether a payment was already attributed, finds nothing, then writes the attribution. On a single process the read and the write are effectively atomic. On four workers pulling off the same queue, both can pass the check before either writes, and the ledger ends up with the same money attributed twice.
Nothing throws. No stack trace. It shows up days later as a reconciliation mismatch, which is the expensive way to learn about it.
Retries sharpen it. A broker redelivery means the duplicate does not need two users racing: one user and a dropped ack is enough.
So I stop enforcing uniqueness in application code. A unique constraint on the idempotency key in the database, insert first, and treat the conflict as "already done" instead of reading first and then deciding. The database is the only participant that sees every worker.
And I run it locally the way it runs in production: worker count turned up, the same message delivered twice on purpose. A green test suite at concurrency one is not evidence of correctness. It is an environment too small to expose the race...
I unpack more of these quiet failure modes on my blog: https://polycratia.com/c/51fdc28e
So where do you draw the line between the invariants your database enforces and the invariants your service layer owns?