mastra-ai/mastra · warning · TripWire

Stream part blocked by ${processor.id}

Error message

Stream part blocked by ${processor.id}

What it means

This TripWire is thrown when a processor's processOutputStream calls the abort() helper for an individual stream chunk. It blocks that stream part (and can trip the whole stream depending on tripwireOptions). The generic message appears because the processor called abort() without a custom reason.

Source

Thrown at packages/core/src/processors/runner.ts:906

              state = new ProcessorState<OUTPUT>({
                processorName: processor.name ?? processor.id,
                ...observabilityContext,
                processorIndex: index,
                createSpan: true,
              });
              processorStates.set(processor.id, state);
            }

            // Track input chunk (before processor transformation)
            state.addInputPart(processedPart);

            const result = await processor.processOutputStream({
              part: processedPart as ChunkType,
              streamParts: state.streamParts as ChunkType[],
              state: state.customState,
              agent: this.agent,
              abort: <TMetadata = unknown>(reason?: string, options?: TripWireOptions<TMetadata>): never => {
                throw new TripWire(reason || `Stream part blocked by ${processor.id}`, options, processor.id);
              },
              ...createObservabilityContext({ currentSpan: state.span }),
              requestContext,
              messageList,
              retryCount,
              writer,
            });

            // Track output chunk and update processedPart
            processedPart = result as ChunkType<OUTPUT> | null | undefined;
            state.addOutputPart(processedPart);
          }
        } catch (error) {
          if (error instanceof TripWire) {
            // Error span for trip-wire abort so it shows as ERROR in traces
            const state = processorStates.get(processor.id);
            state?.span?.error({
              error,

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Inspect the thrown TripWire's processorId to find the offending processor.
  2. Pass a specific reason to abort(), e.g. abort('Blocked token stream: policy hit').
  3. Adjust or remove the stream processor if blocking is not intended; check its tripwireOptions for blocking scope.
  4. Catch TripWire in stream error handling if mid-stream aborts are expected.

Example fix

// before
processOutputStream: async ({ part, abort }) => {
  if (isBad(part)) abort();
  return part;
}
// after
processOutputStream: async ({ part, abort }) => {
  if (isBad(part)) abort('Stream chunk blocked by profanity-filter', { suppress: true });
  return part;
}
Defensive patterns

Strategy: try-catch

Validate before calling

// Review stream processors for abort() without reason before deploying:
const audit = (p) => p.processOutputStream?.toString().includes('abort()') ? warn(p) : ok(p);

Type guard

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

Try / catch

try {
  for await (const chunk of stream) handle(chunk);
} catch (e) {
  if (isTripWire(e)) {
    console.warn('Stream part blocked by processor:', e.processorId, e.message);
  } else throw e;
}

Prevention

When it happens

Trigger: A stream processor inspecting each ChunkType via processOutputStream calls abort() when a chunk violates policy (e.g. streaming output containing banned words), without providing a reason string.

Common situations: Token-level moderation during streaming; redaction processors aborting mid-stream; debugging blocked streams where the generic message obscures which check fired.

Related errors

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