mastra-ai/mastra · warning · TripWire

Tripwire triggered by ${processor.id}

Error message

Tripwire triggered by ${processor.id}

What it means

When a Processor runs inside a workflow step, the library injects a minimal abort function that always throws a TripWire. Calling abort() inside processInput/processOutputResult etc. halts processing (or cancels the run, depending on caller) with the provided reason. The default message includes the processor id when no reason is supplied.

Source

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

        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,
        // Agent reference so processors can access the running agent (e.g. on signal/schedule wake)
        agent,
      } = 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. Pass a meaningful reason to abort('reason') so logs and errors are actionable.
2. Catch TripWire in the surrounding step/run if abort is expected behavior.
3. Check which processor id appears in the message and review its abort conditions.
4. Set retry: true in abort options if the failure should be retriable.

Example fix

// before
abort();
// after
abort('Input failed PII policy check', { metadata: { field: 'email' } });

const willAbort = shouldReject(input);
if (willAbort) abort('Descriptive reason here'); // pass reason at call site, not required pre-check

function isTripWire(e: unknown): e is TripWire {
  return e instanceof TripWire;
}

try {
  await run.start({ inputData });
} catch (e) {
  if (isTripWire(e)) {
    console.warn('Processor aborted:', e.reason, e.processorId);
  } else throw e;
}

When it happens

Trigger: A processor implementation calls abort() with no reason argument; the workflow's cancel() or nestedAbortCb path invokes the injected abort. TripWire then propagates up and is handled by the workflow runner to stop execution.

Common situations: Content-moderation processors tripping on unsafe input; custom guardrail processors rejecting payloads; developers forgetting to pass a descriptive reason string to abort(); cancellation of a suspended/nested run.

Related errors

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

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