Retry & Catch: Declarative Error Handling

A Retry field on a Task state lists one or more error types to catch, along with an interval, a maximum number of attempts, and a backoff rate — Step Functions automatically re-invokes the state according to this policy whenever a matching error occurs, with no retry loop needed inside the underlying Lambda function's code. A Catch field similarly lists error types, but instead of retrying, routes execution to a specified fallback state when a matching error occurs after retries (if any) are exhausted — commonly used to route a failure to a notification step, a compensating transaction, or a dead-letter-style holding state for manual investigation. Because these policies live in the state machine's declarative definition rather than scattered across individual function implementations, an entire workflow's error-handling behavior can be understood and audited by reading one definition, rather than reverse-engineering try/except blocks spread across many separate Lambda functions.