mastra-ai/mastra · warning · TripWire
Tripwire triggered by
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.
Solutions
- Pass a meaningful reason to abort('reason') so logs and errors are actionable.
- Catch TripWire in the surrounding step/run if abort is expected behavior.
- Check which processor id appears in the message and review its abort conditions.
- 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' } }); Defensive patterns
Strategy: try-catch
Validate before calling
const willAbort = shouldReject(input);
if (willAbort) abort('Descriptive reason here'); // pass reason at call site, not required pre-check Type guard
function isTripWire(e: unknown): e is TripWire {
return e instanceof TripWire;
} Try / catch
try {
await run.start({ inputData });
} catch (e) {
if (isTripWire(e)) {
console.warn('Processor aborted:', e.reason, e.processorId);
} else throw e;
} Prevention
- Always pass a reason string to abort().
- Catch TripWire at the run level.
- Log processor id and metadata for triage.
- Use retry: true only for transient guardrail failures.
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
- Error executing processor workflow
- PROCESSOR_MISSING_MESSAGE_LIST
- PROCESSOR_MISSING_MESSAGE_LIST
AI-assisted analysis of mastra-ai/mastra@75dd419e61 (2026-08-30).
Data as JSON: /api/errors/ef2ea8495de6f9f2.
Report an issue: GitHub.
Appendix: 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)