When to use tasks vs. (sub)flows?
Flows block execution while tasks are run in the background. Task run behavior with respect to concurrency and parallelism are controlled by the task runner assigned on the @flow decorator.
If you call a flow, it will not return until its final state is reached. If you call a task, it returns a future immediately and the return value can be retrieved later.
When to use flows vs. subflows?
If you want to build a parent-child relationship to reflect dependencies between flows in a modular way, you can call one flow from another flow.
Slack
View in #prefect-community on Slack
@Stéphan_Taljaard: For :prefect: 2.0 - do you have some general guidelines to use to decide if I should decorate a function(s) with task or flow (i.e. subflows)?
@Kevin_Kho: I think the paradigm is a lot more flexible but for me it would boil down to that flows have properties that tasks don;t (schedules, storage, FlowRunner). I would personally say keep stuff as tasks until you need one of those properties.
Also, flows that group tasks will support retrying together if not already. A common request in Prefect 1 was to retry upstream tasks if a downstream one fails.
I think it also depends what you need visibility for in the UI and you can think about how you would filter for failed flows/tasks