My production build has a bug that the debug build doesn't. A bug that makes no sense, while all unsafe code in the program is on dead paths, and my recent changes should only affect niche multithreaded scenarios but the bug appears in the single threaded case.

I was thinking: "Hm, threads... bugs... Must be a synchronisation or a lock issue".
Then I read the whole "[...] in the single threaded"-part.

I weep for you.

Optimization / minification problems.
Start by looking at the compiler settings.

@magicMirror I doubt Rustc or LLVM would have a bug, so I must've unknowingly broken a contract.

I'm so fucking stupid oh my god

It turns out the bug has been around for as long as the file system API, I just never tested this particular example with a release build.

@lorentz Explanation: pop is a mutation which returns true if it was successful. I wanted to assert that this is always true, so I used debug_assert!.

debug_assert! doesn't execute its argument in production builds. It's intended for expensive assertions. There's a separate assert! macro, which is meant to be the default that you can optimize to debug_assert! if it becomes a problem.

@lorentz so technically it's what @magicMirror said about the compiler settings for prod and test builds being different?

@MammaNeedHummus I think he suspected the same thing I did, which is that I accidentally relied on something unspecified such as the order of asynchronous events or the iteration order of a map. These things can appear consistent while actually depending on very arbitrary low level details that the optimizer is free to change.

In contrast, what actually happened is that I used a language feature to skip an assertion in the release build, and accidentally also skipped the action the success of which was checked by that assertion.