Durable Functions orchestrator code must be deterministic because it replays from the start

An orchestrator function is replayed from its first line each time it resumes. Completed activity results are replayed from the history table rather than re-executed, so the code must produce the same sequence of calls every time.

Any nondeterminism breaks this: current time from the system clock, newly generated GUIDs, random numbers, direct I/O, or work dispatched to another thread. The result is a stuck or failed orchestration, sometimes reported as a non-deterministic workflow detection. Use the orchestration context's current UTC time and GUID helpers, and push every side effect into an activity function.

Two corollaries. Log statements inside an orchestrator appear many times unless guarded by the context's replaying flag, which makes logs confusing rather than wrong. And editing an orchestrator while instances are in flight can break their replay, which is why the versioning guidance is to deploy a new orchestrator name and let old instances finish on the old code.