@Marvin is there a way to configure a task not to store results? I would like to have a task that is always retried, even if it succeeds and I press the retry button

To configure a task in Prefect so it doesn't store results and can be retried even after it successfully runs, you can make use of the

persist_result

and retry functionalities together. ### Configuring the Task 1. Avoid Storing Results: You can ensure that a task does not store its results by setting

persist_result=False

in the task decorator. This tells Prefect not to keep the task's outputs, which could otherwise influence caching and re-running behavior. ### Retry Functionality 2. Retry on Success: Prefect allows you to define custom retry logic using a retry handler function (

retry_condition_fn

). You can use this to create a condition that forces retries based on specific logic that you define. However, Prefect doesn't natively support retrying on success by default—retries are typically initiated on failure. #### Code Example:

python
from prefect import task, flow
import random

@task(persist_result=False, retries=3, retry_delay_seconds=10)
def my_task():
    if random.choice([True, False]):  # Simulate random success/failure
        raise Exception("Simulated failure.")

@flow
def my_flow():
    my_task()

if __name__ == "__main__":
    my_flow()

This setup means your task won't store results, and will retry up to three times, but the retries are only triggered by task failures. If you want it to be manually retried regardless, you'd typically need to re-run the flow, as the retry button in the UI typically triggers after failure states. Here's further reading about configuring tasks and retry logic in Prefect: - Prefect 2.x Task Configuration - Prefect 3.x Task Caching & Persistence - Prefect 3.x Results Configuration Remember, you're asking for a bit of an "adventurous" use case if you're trying to retry on success just for the fun of it. It’s akin to pressing the elevator button repeatedly–maybe unnecessary, but who am I to question human behavior?

marvins answer should also work, but

cache_policy

is the cleaner paradigm nowadays imo

thank you!