Executor instances with the same name in different workflows silently collide

[kshyju]

Summary

Executors are registered and dispatched through a single global, name-keyed namespace with no workflow scoping. When two workflows contain different executor instances that happen to share a name, the second registration is silently dropped and that workflow's executor runs the first workflow's code.

Sharing one executor instance across multiple workflows is supported, works today, and must keep working. This issue is not about that case.

Same failure class as #50, but it needs no duplicate workflow names, so #66 does not address it. Spotted by Ahmed Muhsin (@ahmedmuhsin) while reviewing #66.

Repro

1. Build two workflows, each with its own executor instance under the same name:

   var a = new WorkflowBuilder(new FunctionExecutor<string>("Step", HandlerA)).WithName("WorkflowA").Build();
   var b = new WorkflowBuilder(new FunctionExecutor<string>("Step", HandlerB)).WithName("WorkflowB").Build();

2. Register both:

   options.AddWorkflow(a);
   options.AddWorkflow(b);

3. Run WorkflowB.

Expected: either WorkflowB's Step runs HandlerB, or the conflict is reported at registration.

Actual: WorkflowB's Step runs HandlerA. No error at registration or at runtime.

workflows=2 executors=1
'Step' boundToA=True  boundToB=False

Contrast: the shared-instance case works

FunctionExecutor<string> shared = new("Step", Handler);
var a = new WorkflowBuilder(shared).WithName("WorkflowA").Build();
var b = new WorkflowBuilder(shared).WithName("WorkflowB").Build();

Also gives Executors.Count == 1, but here that is correct: binding.RawValue is reference-equal across both workflows, so collapsing to one registration preserves behavior. Core MAF places no ownership restriction on reusing an executor instance across workflows, unlike using a Workflow as a subworkflow of multiple parents.

RawValue reference equality is therefore what separates legitimate reuse from a real collision.

Root cause

Two places key on the bare executor name and keep the first writer:

1. ExecutorRegistry.Register — TryAdd drops later registrations of the same name without error:

   this._executors.TryAdd(executorName, new ExecutorRegistration(executorId, binding));

2. ServiceCollectionExtensions.BuildWorkflowRegistrationRecursive — one HashSet<string> registeredActivities is threaded through every workflow, and activity names are derived as dafx-{executorName}, so dafx-Step is registered once globally against the first workflow's binding.

Dispatch is name-only, with no workflow context available to disambiguate:

string executorName = WorkflowNamingHelper.ToWorkflowName(activityFunctionName);
if (!durableOptions.Workflows.Executors.TryGetExecutor(executorName, out ExecutorRegistration? registration))

Impact

Silent and result-affecting rather than a startup failure — both workflows appear registered and runnable, and the problem surfaces only as wrong results at runtime. Names like Step, Start, Process, or Validate are natural choices and likely to collide across independently authored workflows.

Suggested fix

In ExecutorRegistry.Register, when executorName is already registered:

• if ReferenceEquals(existing.Binding.RawValue, binding.RawValue), treat as reuse and no-op;
• otherwise throw, naming the executor and both workflows.

This mirrors what #66 did for duplicate workflow names, keeps the shared-instance scenario working, and leaves derived activity names untouched so in-flight orchestration histories stay valid.

Scoping keys by workflow (e.g. {workflowName}/{executorName}) was considered and rejected: it changes every derived activity name, breaking in-flight orchestrations, and registers a shared executor once per referencing workflow for no benefit.

Caveat to settle first: an executor supplied per workflow via a factory produces distinct instances that are logically the same executor, and a reference check would reject it. Same limitation #66 has for calling Build() twice. If that pattern needs support, this needs an identity concept beyond reference equality.

Acceptance criteria

• Reusing a single executor instance across multiple workflows continues to work, covered by a test.
• Two workflows containing different executor instances that share a name no longer silently cross-wire; the conflict is reported at registration time, naming the executor and the workflows involved.
• Derived activity names are unchanged, or any change is called out for backward compatibility with in-flight orchestrations.

[ahmedmuhsin]

I agree with the diagnosis, but not the reference-equality fix. It would turn the extension's flat namespace into a user-facing contract, forcing every workflow in a host to coordinate names like Validate and Step.

Core keeps executor maps per workflow and gives distinct same-named agents different GUID-suffixed executor IDs. Durable strips that suffix to get a stable name, but then collapses distinct agents and executors. Keeping the GUID is not viable because it changes when the object is rebuilt. A workflow-scoped identity, such as {workflowName}/{executorName}, is both stable and unique.

Isolation should be the default. Reusing one plain executor instance would still work unchanged because both scoped registrations can reference the same binding and object. For agents, core creates a fresh AIAgentHostExecutor, and durable creates a fresh session key per dispatch, so same-named agents in different workflows do not share session state today. Distinct agents with the same name are currently collapsed, causing one workflow to run the other's agent. Workflow-derived agents should therefore be scoped too. Only explicitly registered agents that need standalone access require a global public identity.

There is also a third dedupe site in DurableWorkflowsFunctionMetadataTransformer, where registeredFunctions silently collapses same-named activity triggers. A scoped fix needs to cover that path along with ExecutorRegistry and BuildWorkflowRegistrationRecursive.

This changes derived activity names, so the encoding and upgrade impact need an explicit decision. Since this is pre-GA, I would rather take that migration now than permanently require global name coordination. I suggest updating the direction and acceptance criteria around workflow-scoped dispatch identities while preserving explicit instance reuse.