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

  1. Upgrade the host (BpmnCommandApplier / Elsa.Bpmn host package) to the same version as the component producing the commands.
  2. Align all Elsa.Bpmn.* package versions to a single release in your dependency graph.
  3. 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

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


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 can

View on GitHub (pinned to fe9217bdfa)