mastra-ai/mastra · error

Time travel target step not found in execution graph: '${ste

Error message

Time travel target step not found in execution graph: '${steps?.join('.')}'. Verify the step id/path.

What it means

createTimeTravelExecutionParams throws when the requested steps path resolves to an empty execution path in the graph — i.e. the target step was not found. It asks the caller to verify the step id or nested path.

Source

Thrown at packages/core/src/workflows/utils.ts:558

        (!snapshotContext[stepId] || (snapshotContext[stepId] && snapshotContext[stepId].status !== 'suspended'))
      ) {
        // if the step is after the timeTravelled step in the graph
        // and it doesn't exist in the snapshot,
        // OR it exists in snapshot and is not suspended,
        // we don't need to set stepResult for it
        // if perStep is true, and the step is a parallel step,
        // we want to construct result for only the timetraveled step and any step context is passed for
        result = undefined;
      }
      if (result) {
        const formattedResult = removeUndefinedValues(result);
        stepResults[stepId] = formattedResult as any;
      }
    });
  }

  if (!executionPath.length) {
    throw new Error(
      `Time travel target step not found in execution graph: '${steps?.join('.')}'. Verify the step id/path.`,
    );
  }

  const timeTravelData: TimeTravelExecutionParams = {
    inputData,
    executionPath,
    steps,
    stepResults,
    nestedStepResults: nestedStepsContext as any,
    state: initialState ?? snapshot.value ?? {},
    resumeData,
    stepExecutionPath: snapshot?.stepExecutionPath,
  };

  return timeTravelData;
};

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Verify each segment of the steps path matches actual step ids in the workflow definition.
  2. Log or list available step ids for the run and pick the correct one.
  3. Use a simple top-level step id first, then add nested path segments once confirmed.
  4. If ids changed in a refactor, update callers/tests that reference the old ids.

Example fix

// before
timeTravel(runId, ['step-a', 'nested.step-b']);
// after
timeTravel(runId, ['stepA', 'stepB']); // ids matching the workflow definition
Defensive patterns

Strategy: validation

Validate before calling

function assertPathExists(steps: string[], workflowStepIds: string[]) {
  if (!steps.length || !steps.every(s => workflowStepIds.includes(s))) {
    throw new Error(`Unknown time travel path: ${steps.join('.')}; valid: ${workflowStepIds.join(', ')}`);
  }
}

Try / catch

try {
  await workflow.timeTravel(runId, steps);
} catch (e) {
  if ((e as Error).message.includes('target step not found in execution graph')) {
    console.error(`Check path '${steps.join('.')}' against the workflow definition`);
  } else throw e;
}

Prevention

When it happens

Trigger: Calling createTimeTravelExecutionParams (or the timeTravel API) with steps such as ['stepA','subStepB'] where any segment does not resolve in the execution graph — misspelled step id, nested path segments joined with '.' that don't match the graph, or a step id from a different workflow version.

Common situations: Typo in step id; using the nested path of a sub-workflow/mapped step incorrectly; step ids changed after refactoring; targeting steps in a different workflow than the run belongs to.

Related errors


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