elsa-workflows/elsa-core · error · NotSupportedException
The BPMN host command
Error message
The BPMN host command '{command.GetType().Name}' is not supported by this host. What it means
BpmnCommandApplier.ApplyAsync handles a closed set of BPMN host command types; any command outside that set hits the default branch and throws NotSupportedException. The code comments that this can only be reached by a library version that added a new command type the host does not know about, and refusing is preferable to silently skipping the command.
Solutions
- Upgrade the host (BpmnCommandApplier / Elsa.Bpmn host package) to the same version as the component producing the commands.
- Align all Elsa.Bpmn.* package versions to a single release in your dependency graph.
- If you added a custom command, extend ApplyAsync's switch to handle it explicitly.
Example fix
// before <PackageReference Include="Elsa.Bpmn.Host" Version="3.0.0" /> // after <PackageReference Include="Elsa.Bpmn.Host" Version="3.1.0" /> <!-- match interpreter version -->
Defensive patterns
Strategy: try-catch
Try / catch
try { await applier.ApplyAsync(context, commands); }
catch (NotSupportedException ex) { log.LogCritical(ex, "Host/interpreter version mismatch on command {Command}", ex.Message); throw; } Prevention
- Align all Elsa.Bpmn.* package versions in Directory.Packages.props.
- After upgrades, run the BPMN integration tests before deploying.
- Never inject custom host commands without extending the applier.
When it happens
Trigger: Applying a BpmnHostCommand batch where a command instance is of a type added in a newer interpreter/library version than this host supports (mixed assembly versions in the same process).
Common situations: Mismatched package versions after a partial upgrade of Elsa.Bpmn packages; a plugin issuing custom commands the host does not recognize.
Understand the failure class
Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.
Related errors
- The BPMN continuation
- The BPMN work binding kind
- An < : > element declares no ' ', so there is nothing to…
- An < : > element of the ' ' binding declares no ' '.
- BPMN element ' ' is a call activity that names no…
AI-assisted analysis of elsa-workflows/elsa-core@fe9217bdfa (2026-09-13).
Data as JSON: /api/errors/4b951d093d00ee21.
Report an issue: GitHub.
Appendix: source
Thrown at src/modules/Elsa.Bpmn/Hosting/BpmnCommandApplier.cs:67
foreach (var command in commands)
{
switch (command)
{
case BpmnHostCommand.StartWork start:
await StartWorkAsync(start);
break;
case BpmnHostCommand.CancelWorkSubtree cancel:
await CancelWorkSubtreeAsync(cancel);
break;
case BpmnHostCommand.SignalEnclosingScope signal:
await SignalEnclosingScopeAsync(signal);
break;
default:
// The command hierarchy is closed, so this can only be reached by a library version that added a
// command this host has never heard of. Refusing is the only honest answer: silently skipping it
// would run a different process than the one the interpreter decided on.
throw new NotSupportedException($"The BPMN host command '{command.GetType().Name}' is not supported by this host.");
}
memory.SaveWork();
}
}
private async ValueTask StartWorkAsync(BpmnHostCommand.StartWork start)
{
var activity = process.FindWorkActivity(start.BindingRef)
?? throw new InvalidOperationException(
$"BPMN element '{start.ElementId}' binds work '{start.BindingRef}', which activity '{process.Id}' does not map to a child activity.");
// The rule that a nested scope registers no start triggers is enforced by ApplyAsync's pre-scan, before any
// command in the batch is applied — not here, where earlier commands in the same batch could already have
// been applied and persisted.
var workflowExecutionContext = scopeContext.WorkflowExecutionContext;
// The child's context is created up front so that this scope has its id before the child ever runs, and canView on GitHub (pinned to fe9217bdfa)