"It works on my machine" is rarely about the machine. It's a concurrency problem wearing an environment costume.
Containers fixed the half that was library versions and OS paths. The half that still breaks production: your laptop runs one request, one worker, one tab, so every code path gets serialized by the absence of a second actor.
Production has no such shortage.
A customer double-taps submit. A provider redelivers a webhook because your 200 came back slow. A queue redelivers a task after a visibility timeout and a second worker picks up the same row. Read-modify-write in application code is correct right up until something interleaves with you, and locally nothing does.
Arrival order is the other half. On your machine, events arrive in the order you created them. In production the success callback can land before the record it refers to exists, and a handler written as a straight line now has to tolerate arriving at step three first.
So I stop chasing parity and move the invariant to where concurrency actually gets arbitrated: a unique constraint on the natural idempotency key, state transitions enforced by a conditional update instead of an if-statement in the application. Then the default test runs the handler twice, and out of order.
Environment parity is cheap now. Contention parity is the one that rarely ships.
I write up more of these failure modes here: https://polycratia.com/c/2fa28b0f
In practice one of them costs you more, duplicate delivery or out-of-order delivery, and you probably already know which...