restart() is not supported on

Error message

restart() is not supported on ${this.workflowEngineType} workflows

What it means

Thrown by restart() when the run's workflowEngineType is not one of the allowed engines ('default' or 'evented'). restart() — which re-drives a run from its last persisted snapshot after a crash — is only implemented for those engines.

Solutions

Use the default or evented workflow engine for runs you need to restart.
For other engine types, use that engine's own recovery/resume mechanism.
Check how the workflow was constructed (engine type option) before calling restart().
Guard restart() calls behind an engineType check in your recovery code.

Example fix

// before
await run.restart();
// after
if (run.engineType === 'default' || run.engineType === 'evented') {
  await run.restart();
} else {
  // use engine-specific recovery
}

Defensive patterns

Strategy: validation

Validate before calling

if (!['default', 'evented'].includes(run.engineType ?? 'default')) {
  throw new Error(`restart() unsupported for engine ${run.engineType}`);
}

Type guard

function supportsRestart(engineType: string): boolean {
  return engineType === 'default' || engineType === 'evented';
}

Try / catch

try {
  await run.restart();
} catch (e) {
  if (e instanceof Error && e.message.startsWith('restart() is not supported')) {
    // fall back to engine-specific recovery
  } else throw e;
}

Prevention

Only use restart() with default/evented engines.
Centralize crash recovery in one utility that checks engine type.
Document engine choice per workflow.
Pin engine configuration so dev/prod match.

When it happens

Trigger: Calling run.restart() on a workflow constructed with a non-default/experimental engine type (e.g. a legacy or custom engine).

Common situations: Opting into an experimental workflow engine via config and later calling restart-based recovery code paths written for the default engine; copy-pasting crash-recovery code between projects with different engine settings.

Related errors

AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30). Data as JSON: /api/errors/d32d16a7ed9177c6. Report an issue: GitHub.

Appendix: source

Thrown at packages/core/src/workflows/workflow.ts:4709

    });
  }

  protected async _restart({
    requestContext,
    outputWriter,
    tracingOptions,
    actor,
    ...rest
  }: {
    requestContext?: RequestContext<TRequestContext>;
    outputWriter?: OutputWriter;
    tracingOptions?: TracingOptions;
    actor?: ActorSignal;
  } & Partial<ObservabilityContext>): Promise<WorkflowResult<TState, TInput, TOutput, TSteps>> {
    const observabilityContext = resolveObservabilityContext(rest);
    const allowedEngines = ['default', 'evented'];
    if (!allowedEngines.includes(this.workflowEngineType)) {
      throw new Error(`restart() is not supported on ${this.workflowEngineType} workflows`);
    }

    const workflowsStore = await this.#mastra?.getStorage()?.getStore('workflows');
    const snapshot = await workflowsStore?.loadWorkflowSnapshot({
      workflowName: this.workflowId,
      runId: this.runId,
    });

    if (!snapshot) {
      throw new Error(`Snapshot not found for run ${this.runId}`);
    }

    // Parent parallel activeStepsPath can lag behind nested child completion after a crash:
    // children may already be terminal while the parent still lists them as active and
    // re-invokes restart(). Treat terminal snapshots as authoritative and reuse them.
    // See https://github.com/mastra-ai/mastra/issues/20225
    //
    // Only statuses already represented on WorkflowResult are reconstructed here.

View on GitHub (pinned to 75dd419e61)