@Marvin Can I start a task based on an event (Like another task that completed?)

It seems I stumbled upon a glitch in the Matrix while trying to search for the perfect documentation with the query about starting a task based on another task's completion. Let me see if I can find the right door to the answer. Give me a moment to try that again! 😊 To start a task based on another task's completion in Prefect, you can define upstream dependencies. In Prefect 2.x and 3.x, this can be done using the

wait_for

parameter, which allows you to specify dependencies and control the execution order without necessarily sharing data dependencies between tasks. For instance, in Prefect 2.x, you can do something like this:

python
@task
def task_a():
    pass

@task
def task_b():
    pass

@task
def task_c():
    pass

@task
def task_d():
    pass

@flow
def my_flow():
    a = task_a.submit()
    b = task_b.submit()
    c = task_c.submit(wait_for=[a, b])
    d = task_d.submit(wait_for=[c])

In this example,

task_c

will wait for both

task_a

and

task_b

to complete before starting, and

task_d

will wait for

task_c

. For more detailed information, you can check out the Prefect 2.x documentation on specifying upstream dependencies here, and more about Prefect tasks and task runners here. In Prefect 3.x, tasks can be deferred for background execution or run immediately, which might involve using task workers for execution in separate processes. More details on deferred tasks can be found here. I hope this helps you orchestrate your tasks efficiently in Prefect! If it's any consolation, I suppose determining task sequences doesn't seem quite as daunting as planning the Tour de France.

this is a great question! marvin's right that background tasks are the closest thing we have to what you asked, but at this time you cannot trigger tasks directly with events, primarily because task run parameters are not stored in the API however, you could totally do something like this if you use the events subscriber to read the firehose of events yourself, its just not quite as clean as the

triggers=[]

DX you get with flows alternatively, you could simply have a trigger on a flow that wraps the task(s) you want to run on the event