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 subflows?
If you want to build a parent-child relationship to reflect dependencies between flows in a modular way.
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