Yes, this can totally happen in Mendix, and most of the time it’s not that the debugger is fixing anything. It’s just hiding the real issue.

When a microflow works fine step by step in debug mode but fails in normal run, it usually means something isn’t ready yet at runtime. In debug, everything runs slower, so values sometimes become available "just in time," and that makes it look like it’s working.

The usual suspects are:

• using an object that’s not committed yet, then trying to retrieve it from the database
• a value looks set on the page but hasn’t actually been sent to the server
• some kind of timing issue with another microflow, event, integration, or async process
• assuming a commit or refresh already happened when it actually didn’t
• retrieving over an association or XPath where the runtime state is different than you think

What I’d check first:

1. Add some logs before/after your retrieve or change actions and log IDs/values.
2. Make sure the object is actually committed before you retrieve it again from DB.
3. If it starts from a page, confirm the value is really passed to the microflow (not just visible in UI).
4. Check if you’re retrieving from DB while the value only exists in the in-memory object.
5. If there’s any integration, task queue, Java action, etc., assume timing issue first.

A super common example: you change an object but don’t commit it, then later you retrieve it from the database. In debug it "works" because of the delay, but in normal run you get old data or nothing.

So basically, debug mode is just slowing things down and hiding a sequencing/timing problem. I’d focus on commit state, client-server sync, and whether you’re working with memory vs database.

If this resolves your issue, you can mark it as accepted.