This is a total surprise to most “conventional” programmers (e.g., me). In a normal, single-threaded program, once a function is called, no other activity is possible. Selected program data structures can be left in an intermediate (inconsistent) state for an extended period (e.g., during a server call) with no issues, because it will be cleaned up before any other code can see it. The kind of cleanup may well depend on the result from the call, e.g., filing the result away in a global variable.
Now, that “other client code” can be triggered at any point in all those fleeting, intermediate states.
To prevent such hard-to-reproduce bugs, I’m increasingly inclined to just disable every visible code-triggering component that’s on the screen, until the cleanup is complete.
It takes a completely different mindset to sequence your operations such that your data structures are always in a consistent state. If “consistency” is spread across multiple variables, then I’m not sure it’s even possible to guarantee consistency, without some sort of in-memory “transaction” (all-or-nothing) mechanism.