@chris.williamson1996 & @nico.dicagno literally while you were responding I figured out what I believe is the culprit and a workaround that I can confirm fixes it.
I have the clan set in a reusable element (the floating header) and it has its own workflow that handles the logic for doing the private labeling of the app. The project filters are dependent on getting the “clan” custom state set in the header for executing its workflow to apply the appropriate filters for that clan.
So what I did was to put a custom state called “Header Loaded” in the reusable header element defaulting it to “no” and setting it to “yes” as the last step of its onload workflow.
Then in the projects page instead of triggering the workflow that handles the filter configuration logic on page load, I trigger it on the condition once FloatingHeader:HeaderLoaded=“yes”
That solved it and I agree with both of your assessments that likely what’s happening is the app parallelizes workflows in normal operation (perhaps for speed optimization) and the debugger somehow single-threads everything so it starts top to bottom and runs the workflows sequentially in the page.
There should likely be some kind of setting we can toggle for single-threaded vs. parallelized so at least the debugger isn’t altering the app behavior. Anyways I can confirm this workaround solves the issue and I’m all set now. I appreciate both of your help 