FatalError
A fatal error stops retries immediately and fails the step. Use this when you encounter a permanent failure condition that won’t succeed on retry.When to Use FatalError
- Resource not found - API returns 404
- Invalid input - Validation failures
- Permission denied - Authentication/authorization errors (401, 403)
- Business logic violations - Insufficient funds, duplicate orders
- Configuration errors - Missing required environment variables
Basic Usage
API Reference
FatalError Constructor
FatalError Constructor
message(string) - Error message describing the failure
name- Always"FatalError"message- The error messagefatal- Alwaystruestack- Stack trace
FatalError.is(value)- Type guard to check if value is a FatalError
Examples
Validation Errors
Validation Errors
Resource Not Found
Resource Not Found
Business Logic Violations
Business Logic Violations
Type Checking
Type Checking
RetryableError
A retryable error allows you to customize when a step should be retried. Use this when you know how long to wait before the operation might succeed.When to Use RetryableError
- Rate limiting - API returns 429 with Retry-After header
- Temporary unavailability - Service is temporarily down (503)
- Backpressure - System is overloaded but will recover
- Exponential backoff - Progressive retry delays
- Scheduled retries - Retry at a specific time
Basic Usage
API Reference
RetryableError Constructor
RetryableError Constructor
message(string) - Error message describing the failureoptions(object, optional) - Retry configurationretryAfter(number | string | Date, optional) - When to retry- Number: milliseconds
- String: duration (e.g.,
"5s","2m","1h") - Date: specific time to retry
- Default: 1 second (1000ms)
name- Always"RetryableError"message- The error messageretryAfter- Date when the step should be retriedstack- Stack trace
RetryableError.is(value)- Type guard to check if value is a RetryableError
Examples
Rate Limit Handling
Rate Limit Handling
Exponential Backoff
Exponential Backoff
Service Unavailable
Service Unavailable
Scheduled Retry
Scheduled Retry
Duration String Formats
Duration String Formats
Combining FatalError and RetryableError
Use both error types together to handle different failure scenarios appropriately:Best Practices
-
Use FatalError for permanent failures
- Don’t waste retries on errors that will never succeed
- Examples: validation errors, 404s, permission errors
-
Use RetryableError for temporary failures
- Respect rate limits and backpressure signals
- Use appropriate delays based on the error type
-
Set appropriate maxRetries
-
Implement exponential backoff
- Use
getStepMetadata()to access attempt number - Increase delay with each attempt
- Use
-
Make steps idempotent
- Steps may execute multiple times
- Ensure repeated execution is safe
- See Idempotency Guide
-
Include helpful error messages