Constructor
Parameters
string
required
The error message describing what went wrong.
Properties
string
Always set to
"FatalError".string
The error message provided to the constructor.
boolean
Always set to
true. Used internally to identify fatal errors.string
The stack trace where the error was thrown.
Static Methods
(value: unknown) => boolean
Type guard to check if a value is a FatalError.
Usage
Basic Fatal Error
Throw an error that should not be retried:Validation Errors
Mark validation errors as fatal:Invalid Configuration
Fail fast on configuration errors:Conditional Fatal vs Retryable
Decide whether to retry based on error type:Permission Errors
Mark permission errors as fatal:Type Guard Usage
Check if an error is fatal:Business Logic Errors
Fail on business rule violations:Quota Exceeded
Mark quota errors as fatal:When to Use FatalError
UseFatalError when:
- Validation fails: Invalid input that won’t change on retry
- Authorization fails: Permission errors that retrying won’t fix
- Business rules violated: Logic errors that are permanent
- Resource not found: Missing resources that won’t appear on retry
- Configuration errors: Invalid settings that need manual correction
- Client errors (4xx): HTTP client errors that indicate bad requests
FatalError for:
- Network timeouts: Use
RetryableErrorinstead - Server errors (5xx): Use
RetryableErrorinstead - Rate limits: Use
RetryableErrorwith appropriateretryAfter - Temporary failures: Anything that might succeed on retry
Notes
- Fatal errors cause the step to fail immediately without retries
- The error is bubbled up to the workflow logic and can be caught with try/catch
- Unlike normal errors, fatal errors bypass the default retry mechanism
- The
fatalproperty is used internally to identify fatal errors - Use
FatalError.is()to check if an error is fatal
Related
- RetryableError - Throw an error with retry configuration
- getStepMetadata - Get current step attempt number