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

[kokosda]

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)

[cgillum]

Is this analyzer for the Durable Task Framework or for Durable Functions? We have an analyzer for the latter already, so I’m wondering whether you could use that one.

[kokosda]

The intent on my side has been to support both Durable Task Framework and Durable Functions orchestrator code, focusing on determinism issues in the orchestrator logic itself rather than DF-specific APIs or bindings.

I’m aware of the existing Durable Functions analyzer, and from what I understand, it’s scoped specifically to DF usage patterns. That made me curious whether the tighter DF-only scope is intentional (e.g., reliance on DF SDK context), or if there was ever consideration of something more framework-level that would also apply to DTF scenarios.

In practice, I’ve been treating the two as complementary, but I’d be interested in your take on why the official analyzer is limited to Durable Functions only.

[cgillum]

We focused just on Durable Functions because that's the product we officially support, so we wanted to focus on that.

To answer your questions:

Do you see value in earlier (compile-time) determinism detection vs. runtime-only safeguards?

Yes, absolutely.

Are there known edge cases where static analysis could produce false confidence?

Accounting for every possible non-determinism case can be challenging, but I think people would generally have something that can catch 80+% of issues vs. not having anything at all.

Are there determinism pitfalls you see in the wild that tooling often misses?

The biggest determinism issue that I think static tooling can't easily detect is determinism issues introduced by code changes. For example, an orchestration that originally did ActivityA --> ActivityB and then is updated to do ActivityA --> ActivityC --> ActivityB. For new instances this is fine, but for existing instance that have completed ActivityA but not ActivityB, they will fail with a non-determinism error.