At this time the two things to be aware of that are different when debugging vs not debugging are these:
-
Timing. When debugging any async work (i.e. batch job) inherits the debug attribute. That other process shows up as a separate debug session in the debugging tool and waits for instructions (step/run/etc) instead of immediately beginning to execute.
-
Select behavior. When debugging all DB queries are altered from SELECT to SELECT *. This unfortunate discrepancy in behavior is necessary to enable conditional breakpoints based on values that are not otherwise needed for the logic flow.
To diagnose which of these causes the works/doesn’t work difference you are seeing:
- check for race conditions in related processes/debug sessions (#1) and make them run in different orders within the debugger.
- use the same diagnostic method Brendan suggested above to determine if the DB query difference is the cause of the problem.
Race condition is a logic flaw in the application. There is no guarantee about when the secondary process executes.
Difference because of the DB query is a platform bug and needs reported along with steps to reproduce. The choice of querying a named set of fields vs all fields should not result in a functional difference.