Retries
Configure retries on any task:Retry delay and backoff
Control the wait time between retries:| Parameter | Default | Description |
|---|---|---|
retries | 0 | Maximum retry attempts |
retry_delay | 1.0 | Seconds before the first retry |
retry_backoff | 2.0 | Multiplier applied after each retry |
Check attempt number
Inside a task, check which attempt you’re on:Timeouts
Set a maximum execution time for a task:TaskTimeoutError is raised.
Handle timeout errors
When waiting for a result, you can catch timeout-specific errors:Error types
UpNext raises specific exceptions when tasks fail:TaskExecutionError
Raised when a task finishes with a failed or cancelled status:
TaskTimeoutError
A subclass of TaskExecutionError, raised specifically when a task exceeds its timeout:
Catching errors
Both.wait() and future.result() always raise on failure — you never get a TaskResult with ok=False. Use try/except to handle errors:
gather with return_exceptions=True:
Dead-letter queue
Jobs that exhaust all retry attempts are moved to the dead-letter queue (DLQ). You can browse and manage DLQ entries from the dashboard, or via the server’s REST API at/api/v1/dlq.
The DLQ stores:
- The original job payload
- The error that caused the final failure
- All attempt metadata
Lifecycle hooks
Attach callbacks to specific task events:on_start, on_success, on_failure, on_retry, on_complete.