Compile-time detection of non-determinism in Durable Functions orchestrators

[kokosda]

Hi Durable Functions team,

Non-determinism in orchestrator code is something I’ve repeatedly seen surface only at runtime - often after deployment - even when the code passed review.
Typical examples include DateTime usage, async calls outside activity boundaries, or other subtle sources of non-deterministic behavior.

To mitigate this earlier in the lifecycle, I implemented a Roslyn-based static analyzer that inspects Durable Functions orchestrator code at build time and flags common non-deterministic patterns. The analyzer is used to catch these issues before deployment.

I’d be very interested in the maintainers’ perspective:

• Do compile-time determinism checks provide meaningful value alongside existing runtime safeguards?
• Are there determinism edge cases where static analysis is likely to be misleading or incomplete?
• Are there common pitfalls in real-world DF orchestrator code that tooling tends to miss?

Appreciate any thoughts or guidance from your experience maintaining Durable Functions.

(For context: https://github.com/kokosda/dtf-determinism-analyzer)