Early (compile-time) detection of non-determinism in orchestrators — maintainer perspective?

Hi folks,

Non-determinism in Durable Task / Durable Functions orchestrators is a recurring pain point I’ve seen in production systems - especially cases that pass code review but later fail at runtime due to subtle issues (DateTime usage, async calls outside activities, hidden I/O, etc.).

To address this, I implemented a Roslyn-based static analyzer that inspects the orchestrator code at build time and flags common non-deterministic patterns before deployment.

I’m curious to sanity-check this approach with maintainers:
- Do you see value in earlier (compile-time) determinism detection vs. runtime-only safeguards?
- Are there known edge cases where static analysis could produce false confidence?
- Are there determinism pitfalls you see in the wild that tooling often misses?

I’m especially interested in whether this aligns with how you’ve seen customers
struggle with determinism in practice.

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