[.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.