mastra-ai/mastra · error

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

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.

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)

Solutions

1. Use the default or evented workflow engine for runs you need to restart.
2. For other engine types, use that engine's own recovery/resume mechanism.
3. Check how the workflow was constructed (engine type option) before calling restart().
4. 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
}

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

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

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;
}

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

• Snapshot not found for run ${this.runId}
• Workflow ${workflowId} not found
• Workflow ID is required
• Failed to stream workflow: ${response.statusText}
• Response body is null

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