Steps and Evaluators
When a step or evaluator throws, we retry it automatically with exponential backoff. After all retries are exhausted, the error propagates to the workflow and the execution fails. Default retry behavior:| Setting | Default |
|---|---|
initialInterval | 10s |
backoffCoefficient | 2.0 |
maximumAttempts | 3 |
nonRetryableErrorTypes | ['ValidationError', 'FatalError'] |
options.activityOptions property — see Step Options.
Workflows
Errors in the workflowfn itself are not retried. If the workflow function throws — or if a step throws after exhausting retries — the workflow execution fails.
You can catch step errors with try/catch and handle them however you want:
workflow.ts
FatalError and ValidationError
Sometimes retrying won’t help — the API key is invalid, the resource doesn’t exist, or the data is fundamentally wrong. For these cases, throwFatalError or ValidationError to fail immediately without retries.
| Error | Use when |
|---|---|
FatalError | The failure is not recoverable. Retrying would not help (e.g. invalid API key, resource not found, business rule violation). |
ValidationError | The data is invalid. Use for custom validation checks alongside the framework’s built-in schema validation. |
@outputai/core:
steps.ts
Schema Validation
The framework validates inputs and outputs automatically using your Zod schemas. When validation fails, it throws aValidationError with a message that tells you exactly what went wrong.
Steps and evaluators: Input is validated against inputSchema before fn runs. The return value is validated against outputSchema after fn returns. If either fails, the step fails immediately (no retries).
Workflows: Input is validated against inputSchema before the workflow starts. Output is validated against outputSchema after the workflow returns. If either fails, the execution fails.
The error message includes context like "Step lookupContact input validation failed: ..." so you can trace exactly where and why validation failed.