mastra-ai/mastra · info · Error

TRIPWIRE:${reason || 'Processor aborted'}

Error message

TRIPWIRE:${reason || 'Processor aborted'}

What it means

This is the sentinel Error thrown by the `abort(reason?, options?)` function injected into a processor's execution context. It is not a real failure: the handler catches it, detects the `TRIPWIRE:` prefix (or the tripwireTriggered flag), and converts it into a `{ success: false, tripwire: { triggered: true, reason, metadata } }` response, mirroring Mastra's tripwire semantics for processors halting agent flow.

Source

Thrown at packages/server/src/server/handlers/processors.ts:389

            throw error;
          }
          throw new HTTPException(500, {
            message: `Error executing processor workflow: ${error.message}`,
          });
        }
      }

      // Handle individual processor execution
      // Create the abort function for tripwire support
      let tripwireTriggered = false;
      let tripwireReason: string | undefined;
      let tripwireMetadata: unknown;

      const abort = (reason?: string, options?: { retry?: boolean; metadata?: unknown }) => {
        tripwireTriggered = true;
        tripwireReason = reason;
        tripwireMetadata = options?.metadata;
        throw new Error(`TRIPWIRE:${reason || 'Processor aborted'}`);
      };

      // Build the context based on phase
      const baseContext = {
        abort,
        retryCount: 0,
        messages: messageList.get.all.db(),
        messageList,
        state: {},
      };

      try {
        let result: any;

        // Execute the specific phase method on the individual processor
        switch (phase) {
          case 'input':
            if (!processor.processInput) {

View on GitHub (pinned to 75dd419e61)

Solutions

1. Treat the tripwire response as expected behavior — check `result.tripwire.triggered` and `reason` in the response body instead of treating it as an error.
2. Always pass a descriptive reason to `abort()` so downstream consumers can act on it.
3. Use `options.metadata` to attach structured context (matched terms, scores) for programmatic handling.
4. If you see the raw `TRIPWIRE:` Error escaping to your own catch, you invoked the processor outside the server handler — replicate the handler's prefix check or use core's Tripwire handling.

Example fix

// before
} catch (e) {
  console.error('Processor crashed:', e);
}
// after
} catch (e) {
  if (e instanceof Error && e.message.startsWith('TRIPWIRE:')) {
    handleTripwire(e.message.replace('TRIPWIRE:', ''));
  } else {
    throw e;
  }
}

function isTripwireError(e: unknown): e is Error & { tripwireReason?: string } {
  return e instanceof Error && e.message.startsWith('TRIPWIRE:');
}

try {
  const result = await runProcessorPhase(id, phase, messages);
  if (result.tripwire?.triggered) {
    console.warn(`Processor aborted: ${result.tripwire.reason}`, result.tripwire.metadata);
    return handleTripwire(result.tripwire);
  }
  return result;
} catch (e) {
  if (isTripwireError(e)) {
    return handleTripwire({ reason: e.message.replace('TRIPWIRE:', '') });
  }
  throw e;
}

When it happens

Trigger: Calling `context.abort('reason', { metadata })` (or `abort()` with no args) inside processInput/processOutputResult/etc. during POST /processors/:id/execute — the thrown `Error('TRIPWIRE:...')` propagates to the handler's catch block.

Common situations: A moderation/PII processor detects disallowed content and intentionally stops the run; a developer accidentally calls abort in normal control flow and is surprised execution stops; a custom processor aborts without a reason, producing the generic 'Processor aborted' message.

Related errors

• Tripwire triggered by ${processor.id}
• Tripwire triggered by ${processor.id}
• Tripwire triggered in workflow ${workflow.id}
• Tripwire triggered by ${processor.id}
• Processor tripwire triggered

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