mastra-ai/mastra · warning · TripWire

Tripwire triggered by ${processor.id}

Error message

Tripwire triggered by ${processor.id}

What it means

Within processor step execution, a local abort() helper throws a TripWire to signal that a processor halted the stream. The reason defaults to "Tripwire triggered by <processor.id>". This is the evented-workflow adapter re-raising a tripwire originating from a processor (abort can also be invoked on cancel).

Source

Thrown at packages/core/src/workflows/evented/workflow.ts:847

        steps,
        usage,
        messageId,
        rotateResponseMessageId,
        // toolResult phase fields
        toolName,
        toolCallId,
        args: toolCallArgs,
        toolResultValue,
        providerExecuted,
        // Shared processor states map for accessing persisted state
        processorStates,
        // Abort signal for cancelling in-flight processor work (e.g. OM observations)
        abortSignal,
      } = input;

      // Create a minimal abort function that throws TripWire
      const abort = (reason?: string, options?: { retry?: boolean; metadata?: unknown }): never => {
        throw new TripWire(reason || `Tripwire triggered by ${processor.id}`, options, processor.id);
      };
      const initialMessageId = messageId;
      let currentMessageId = messageId;
      const rotateCurrentResponseMessageId = rotateResponseMessageId
        ? () => {
            currentMessageId = rotateResponseMessageId();
            return currentMessageId;
          }
        : undefined;
      const defaultOutputResult: OutputResult = {
        text: '',
        usage: { inputTokens: 0, outputTokens: 0, totalTokens: 0 },
        finishReason: 'unknown',
        steps: [],
      };

      const buildProcessorSpanInput = () => {
        switch (phase) {

View on GitHub (pinned to 75dd419e61)

Solutions

1. Treat this as an expected control-flow signal: catch TripWire and inspect reason/processor id instead of treating it as a crash.
2. Have the processor call abort('specific reason') so downstream consumers see why the tripwire fired.
3. If the abort is unexpected, review the processor's gating logic and input content that triggered it.

Example fix

// before
try {
  await workflow.start(...);
} catch (e) {
  throw e;
}

// after
try {
  await workflow.start(...);
} catch (e) {
  if (e instanceof TripWire) {
    console.warn('Processor halted run:', e.message);
    return { aborted: true, reason: e.message };
  }
  throw e;
}

const assertProcessorGates = (p: { id: string; abort?: Function }) => {
  if (typeof p.abort !== 'function') {
    console.warn(`Processor ${p.id} may abort; ensure callers handle TripWire`);
  }
};

const isTripWire = (e: unknown): e is TripWire & { processorId?: string } =>
  e instanceof TripWire;

try {
  await run;
} catch (e) {
  if (isTripWire(e)) {
    return { status: 'aborted', reason: e.reason, processor: (e as any).processorId };
  }
  throw e;
}

When it happens

Trigger: A processor calls the provided abort callback (or the run is cancelled) while a processor step is streaming; the message surfaces in the run's error/step output with the processor's id in the reason.

Common situations: Content moderation/guardrail processors aborting on policy violations; custom processors calling abort() without a custom reason; user cancelling the workflow run mid-processor.

Related errors

• Tripwire triggered by ${processor.id}
• Processor tripwire triggered
• TRIPWIRE:${reason || 'Processor aborted'}
• Aborted by processor
• MAP_RESULTS_STEP_UNSUPPORTED_MODEL

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