Early (compile-time) detection of non-determinism in orchestrators — maintainer perspective?
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- csharp
- Domain
- distributed-systems, tooling
Research direction
Start by reviewing the issue's description of Durable Task orchestrator determinism and the linked Roslyn-based analyzer repository. Compare the analyzer's stated checks with the runtime pitfalls mentioned in the issue and look for maintainer guidance or an explicit scope. Done would require a decided direction on whether and how compile-time detection belongs in the project.
Written by the indexing model from the issue text.
Description
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)
- Dominant language
- C#
- Stars
- 1.7k
- Forks
- 335
- Avg merge
- 5d 3h
- Merged PRs (30d)
- 8
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/durabletask
-
Difficulty 4/5 3-5 days Newbie friendliness 55/100
Azure/durabletask#1398 · 2 comments ·
Maintainers usually reply within 3 days
-
Azure Storage backend: control queue partition left unowned for hours/days after lease expiresMay be free again @nytian claimed this 32 days ago, and no pull request is open. Open
Azure/durabletask#1389 · 1 comment · 1 assignee ·
Maintainers usually reply within 3 days
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Azure/durabletask#1332 ·
Maintainers usually reply within 3 days
-
Difficulty 3/5 1-2 days Newbie friendliness 58/100
Azure/durabletask#1318 · 1 comment ·
Maintainers usually reply within 3 days
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/durabletask#1297 ·
Maintainers usually reply within 3 days
All issues in Azure/durabletask
Similar issues
-
copilot documentation
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 2 days
-
Bug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 4 days
-
needs triage
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
spectreconsole/spectre.console#2221 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
godotengine/godot-docs#12428 ·
Maintainers usually reply within 1 day