mastra-ai/mastra · error · HTTPException

Error executing processor workflow: ${error.message}

Error message

Error executing processor workflow: ${error.message}

What it means

This HTTP 500 wraps any unexpected exception thrown while starting/running a workflow processor's run inside the execute endpoint. HTTPExceptions are re-thrown as-is; everything else is converted, so the original error text appears after the 'Error executing processor workflow:' prefix.

Source

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

            } else if ('messageList' in output && output.messageList instanceof MessageList) {
              outputMessages = output.messageList.get.all.db();
            }
          }

          return {
            success: true,
            phase,
            messages: outputMessages,
            messageList: {
              messages: outputMessages,
            },
          };
        } catch (error: any) {
          // Re-throw HTTP exceptions
          if (error instanceof HTTPException) {
            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'}`);
      };

View on GitHub (pinned to 75dd419e61)

Solutions

  1. Read the wrapped `error.message` in the response to identify the original failure.
  2. Add try/catch inside the processor's step and log/normalize errors before they bubble up.
  3. Make the step tolerant of the minimal inputData the execute endpoint constructs (empty model, empty steps).
  4. Test the processor step directly with a unit test using the same phase-specific inputData shape.

Example fix

// before
const result = await processor.processInput({ messages });
// after
try {
  const result = await processor.processInput({ messages });
} catch (err) {
  logger.error('processor step failed', err);
  throw new Tripwire('processing unavailable');
}
Defensive patterns

Strategy: try-catch

Validate before calling

const detail = await fetch(`/api/processors/${processorId}`).then(r => r.json());
if (!detail.isWorkflow) {
  throw new Error('This endpoint executes workflow processors via createRun; confirm the processor type');
}

Type guard

function isHttpWrappedError(msg: string): boolean {
  return msg.startsWith('Error executing processor workflow:');
}

Try / catch

try {
  const res = await fetch(url, options);
  if (!res.ok) {
    const { message } = await res.json();
    if (isHttpWrappedError(message)) {
      const original = message.replace('Error executing processor workflow: ', '');
      console.error('Underlying processor error:', original);
    }
    throw new Error(message);
  }
  return await res.json();
} catch (e) {
  console.error(e);
  throw e;
}

Prevention

When it happens

Trigger: POST /processors/:id/execute on a workflow processor where `processor.createRun()` or `run.start({ inputData })` throws — e.g. invalid inputData shape rejected by a step's schema, a bug in a step function, or an unhandled rejection in processor setup.

Common situations: Processor step assumes fields the execute endpoint's synthetic context leaves empty (model: '', steps: []); zod validation failure in a step's inputSchema; async network call inside a step failing; type errors from passing a MessageList where a plain array is expected.

Related errors


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