[.NET] Throw when AddWorkflow is given a duplicate workflow name

[Shyju Krishnankutty (kshyju)]

AddWorkflow used an indexer assignment, so registering a workflow under a name that was already taken silently replaced the existing one. Because ExecutorRegistry is first-writer-wins while the workflow dictionary was last-writer-wins, a collision left the two registries disagreeing.

AddWorkflow now throws when a name maps to a different workflow instance. Re-registering the same instance remains a no-op, which the recursive sub-workflow registration relies on.

Fixes #50

[Copilot]

Pull request overview

This PR hardens durable workflow registration by preventing silent overwrites when multiple workflows share the same name, which previously could leave the workflow registry and executor registry in a contradictory state. It aligns workflow registration behavior with the existing “duplicate name is an error” pattern used elsewhere (e.g., agent registration), while preserving idempotent re-registration of the same instance (needed for recursive sub-workflow discovery).

Changes:

• Update DurableWorkflowOptions.AddWorkflow to throw when a different workflow instance is registered under an already-used name, while treating re-registering the same instance as a no-op.
• Add unit tests covering duplicate-name throwing, case-insensitive name collision, idempotent same-instance registration, and explicit + recursive sub-workflow registration.
• Add an Unreleased changelog entry documenting the behavior change.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

File	Description
dotnet/tests/Microsoft.Agents.AI.DurableTask.UnitTests/Workflows/DurableWorkflowOptionsTests.cs	Adds unit coverage for duplicate workflow-name handling and idempotent/sub-workflow registration scenarios.
dotnet/src/Microsoft.Agents.AI.DurableTask/Workflows/DurableWorkflowOptions.cs	Enforces “unique workflow name per instance” by throwing on collisions while allowing same-instance re-add.
dotnet/src/Microsoft.Agents.AI.DurableTask/CHANGELOG.md	Documents the workflow registration behavior change under Unreleased.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

Suppressed comments (2)

dotnet/src/Microsoft.Agents.AI.DurableTask/CHANGELOG.md:5

• Changelog entries in this file consistently link to the PR (pull/NN) rather than only the issue. This new entry links to the issue (#50) but not the PR, which makes it harder to trace the change back to the implementation.

- Fixed `AddWorkflow` silently overwriting an existing workflow registered under the same name, which left the workflow and executor registries inconsistent. Registering a different workflow under a name that is already taken now throws, while re-registering the same workflow instance remains a no-op ([#66](https://github.com/microsoft/agent-framework-durable-extension/pull/66))

dotnet/src/Microsoft.Agents.AI.DurableTask/Workflows/DurableWorkflowOptions.cs:79

• If RegisterWorkflowExecutors throws after the workflow is added to the dictionary, a retry with the same Workflow instance will now short-circuit here and never attempt to register executors/agents again, leaving DurableWorkflowOptions.Workflows and Executors potentially inconsistent. Consider re-running RegisterWorkflowExecutors when the same instance is re-added so retries can self-heal (Executors.Register is TryAdd-based and agent registration is guarded).

            // The same instance was already registered, so its executors are registered too.
            return this;
        }

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[Shyju Krishnankutty (kshyju)]

Heads up Ahmed Muhsin (@ahmedmuhsin) — since you'd already approved, note that 1ed4d03 contains a small code change beyond the changelog tag, so it may be worth a second look.

It addresses a comment the Copilot reviewer suppressed on an earlier pass: because re-adding the same instance is now a no-op, a failure part-way through RegisterWorkflowExecutors would leave the workflow in _workflows with its executors only partially registered, and any retry with that same instance would short-circuit and never finish the job.

Fix is a one-line reorder — register executors first, then add to the dictionary:

\\csharp
// Register executors first so a failure part-way through leaves no entry behind and a retry re-runs registration.
this.RegisterWorkflowExecutors(workflow);
this._workflows[workflow.Name] = workflow;
\\

Safe because RegisterWorkflowExecutors never reads _workflows, and it's idempotent anyway (TryAdd plus the ContainsAgent guard), so a retry re-runs cleanly.

Being upfront: this is defensive rather than a bug I could reach from a test. Triggering it needs RegisterWorkflowExecutors to throw and the caller to catch and retry during DI configuration, and I couldn't construct that without adding a seam I didn't think was worth it. Happy to revert if you'd rather keep the diff strictly scoped to #50.

334 unit tests pass and dotnet format --verify-no-changes is clean.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.