Retry strategies
Retry strategies make your data pipelines more resilient by automatically retrying operations that fail due to transient issues like network timeouts, temporary service unavailability, or rate limiting.
Configuration levels​
Configure retry strategies at different levels in your Ascend project:
| Level | Method | Example |
|---|---|---|
| YAML Component | retry_strategy: field at the second indent level | retry_strategy: stop_after_attempt: 3 |
| SQL Component | Config Jinja block | {{ config(retry_strategy=retry_strategy(stop_after_attempt=2)) }} |
| Python Component | Decorator parameter | @read(retry_strategy=retry_strategy(stop_after_attempt=5)) |
| Project defaults | ascend_project.yaml | Applies to all components unless overridden |
Strategy parameters​
Two main configuration parameters control retry behavior:
stop_after_attempt​
Maximum number of retry attempts before giving up. This includes the initial attempt, so stop_after_attempt: 3 means one initial attempt plus two retries.
stop_after_delay​
Maximum retry time in seconds. Retries will stop after this duration regardless of attempt count.
Combined limits​
When using both parameters together, retries will stop as soon as the first limit is reached (either the maximum attempts or the time limit).
When to use retry strategies​
Retry strategies are most effective for handling:
- Transient network issues: Temporary connectivity problems or timeouts
- Service unavailability: Brief outages of external APIs or databases
- Rate limiting: Temporary throttling by external services
- Resource contention: Temporary locks or busy resources
Next steps​
- Learn how to implement retry strategies in your Components
- Configure Project-level defaults for consistent retry behavior
- Use Profiles to manage environment-specific retry settings