"It works on my machine" usually means "every dependency answered instantly and nothing failed."
That is not an environment difference. It is a coverage gap.
Locally the third-party call is a stub or a hop to localhost, so it comes back in a millisecond. In production it sometimes overruns the gateway timeout, and now you are running the half of the handler that only exists after a failure: a half that has never run anywhere, on any machine.
The gap repeats itself once you start looking. A connection pool does not saturate with one request in flight. Retries do not fire, so you do not find out whether the write path is idempotent. The database sits near-empty, so a missing index costs you almost nothing until the table grows and the planner flips to a sequential scan. Uploads feel instant because the file did not leave the box.
So I stopped chasing package parity and I make the slow path reachable instead. Latency and failure injection in the dependency clients, behind a flag. A dataset shaped like production instead of like a fixture. The service running with the same worker and concurrency topology it gets in production.
Matching versions is the cheap part. Matching timing and failure is the real work, and it decides whether your first production incident is a surprise.
I'd like to know which slow path you exercise on purpose before shipping: timeouts, pool exhaustion, partial writes...