Skip to main content

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:

LevelMethodExample
YAML Componentretry_strategy: field at the second indent levelretry_strategy:
stop_after_attempt: 3
SQL ComponentConfig Jinja block{{ config(retry_strategy=retry_strategy(stop_after_attempt=2)) }}
Python ComponentDecorator parameter@read(retry_strategy=retry_strategy(stop_after_attempt=5))
Project defaultsascend_project.yamlApplies 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​