Clarify behavior of interruptible map tasks

docs/user_guide/flyte_fundamentals/optimizing_tasks.md

@@ -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's robust retry mechanism enhances the reliability of distributed computing environments by effectively managing task failures. This section delves into the configuration and application of retries, ensuring you can maximize task resilience and efficiency.
 
-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:
@@ -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