Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify behavior of interruptible map tasks #5845

Merged
merged 7 commits into from
Oct 23, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 38 additions & 10 deletions docs/user_guide/flyte_fundamentals/optimizing_tasks.md
Original file line number Diff line number Diff line change
Expand Up @@ -52,16 +52,26 @@ represents the cache key. Learn more in the {ref}`User Guide <cache-offloaded-ob

## Retries

Flyte also allows you to automatically retry failing tasks in the case of
system-level or catastrophic errors that may arise from issues that don't have
anything to do with user-defined code, like network issues and data center
outages.
Flyte also allows you to automatically retry failing tasks in the case of system-level or catastrophic errors that may arise from issues that don’t have anything to do with user-defined code, like network issues and data center outages. This section delves into the configuration and application of retries.

The following version of the `compute_mean` task simulates these kinds of
errors by randomly throwing a `RuntimeError` 5% of the time:
### Understanding Retry Types

Flyte categorizes errors into two main types, each influencing the retry logic differently:

- **SYSTEM**: These errors arise from infrastructure-related failures, such as hardware malfunctions or network issues. They are typically transient and can often be resolved with a retry.
- **USER**: These errors are due to issues in the user-defined code, like a value error or a logic mistake, which usually require code modifications to resolve.



### Configuring Retries

Retries in Flyte are configurable to address both USER and SYSTEM errors, allowing for tailored fault tolerance strategies:

- **User Errors**: Set the `retries` attribute in the task decorator to define how many times a task should retry after a USER error. This is straightforward and directly controlled in the task definition.

```{code-cell} ipython3
import random
from flytekit import task

@task(retries=3)
def compute_mean(data: List[float]) -> float:
Expand All @@ -70,10 +80,28 @@ def compute_mean(data: List[float]) -> float:
return sum(data) / len(data)
```

```{note}
Retries only take effect when running a task on a Flyte cluster.
See {ref}`Fault Tolerance <fault-tolerance>` for details on the types of errors that will be retried.
```

- **System Errors**: Managed at the platform level through settings like `max-node-retries-system-failures` in the FlytePropeller configuration. This setting helps manage retries without requiring changes to the task code.

Additionally, the `interruptible-failure-threshold` option in the node-config key defines how many system-level retries are considered interruptible. This is particularly useful for tasks running on preemptible instances.

For more details, refer to the [Flyte Propeller Configuration](https://docs.flyte.org/en/latest/deployment/configuration/generated/flytepropeller_config.html#config-nodeconfig).


### Interruptible Tasks and Map Tasks

Tasks marked as interruptible can be preempted and retried without counting against the USER error budget. This is useful for tasks running on preemptible compute resources like spot instances.

For map tasks, the interruptible behavior aligns with that of regular tasks. The `retries` field in the task annotation is not necessary for handling SYSTEM errors, as these are managed by the platform's configuration. Alternatively, the USER budget is set by defining retries in the task decorator.

Map Tasks: The behavior of interruptible tasks extends seamlessly to map tasks. The platform's configuration manages SYSTEM errors, ensuring consistency across task types without additional task-level settings.

### Advanced Retry Policies

Flyte supports advanced configurations that allow more granular control over retry behavior, such as specifying the number of retries that can be interruptible. This advanced setup helps in finely tuning the task executions based on the criticality and resource availability.

For a deeper dive into configuring retries and understanding their impact, see the [Fault Tolerance](https://docs.flyte.org/en/latest/concepts/fault-tolerance.html) section in the Flyte documentation.


## Timeouts

Expand Down
Loading