In Prefect, how does calling a task with .submit() differ from calling it directly?

## Two calling conventions, one function A task-decorated function can be invoked two ways inside a flow, and the difference is where the work runs and what you get back. **Direct call.** `rows = fetch("eu")` creates a task run and executes it inline, in the flow's own thread, returning the actual return value. The flow blocks until it finishes. This is the simplest form and is exactly right for a linear pipeline where each step needs the previous step's output anyway. **Submitted call.** `fut = fetch.submit("eu")` creates the task run and hands it to the flow's **task runner**, returning a `PrefectFuture` immediately. The flow continues to the next statement while the work proceeds. This is how you get concurrency in Prefect. ```python futures = [fetch.submit(r) for r in regions] rows = [f.result() for f in futures] ``` All the fetches start before the first `.result()` blocks, so the wall-clock cost is roughly the slowest fetch rather than the sum. ## What a future is and how you resolve it A `PrefectFuture` is a handle to a task run that may still be in flight. The operations you need: - `future.result()` — blocks until the run finishes and returns its value. If the run failed, the exception is re-raised here, which is what makes failure propagate to the flow. Pass `raise_on_failure=False` to get the failed state back instead of an exception when you want to handle it yourself. - `future.wait()` — blocks until the run reaches a final state without returning the value. - `future.state` — the run's state object, useful for inspecting rather than raising. The timing detail that catches people out: exceptions surface when you resolve, not when you submit. A loop that submits fifty tasks and only later collects results will not raise on the fifth failure until you reach its `.result()`. ## How dependencies are expressed There is no explicit edge syntax. Two mechanisms cover everything: **Data dependencies.** Pass a future straight into another task: ```python raw = extract.submit(region) clean = transform.submit(raw) # waits for raw, receives its value ``` Prefect resolves the future before running `transform`, so the second task run cannot start until the first completes and it receives the plain value, not the future. **Ordering-only dependencies.** When the second task does not consume the first's output — it reads a table the first wrote, say — use the reserved keyword: ```python refresh.submit(wait_for=[load_future]) ``` That is the equivalent of an edge that carries no payload, and it is the correct fix for the classic bug where two submitted tasks touching the same table race because nothing linked them. ## Where the concurrency actually comes from `.submit()` on its own does not create threads — it delegates to the flow's task runner. The default runner in Prefect 3 executes submitted runs as threads inside the flow process, which is genuinely concurrent for I/O-bound work (HTTP calls, warehouse queries, object-storage reads) and largely pointless for CPU-bound pure-Python work because of the interpreter lock. Swapping in a distributed runner changes where submitted runs execute without changing any of the `.submit()` calls. Directly-called tasks bypass the runner entirely, no matter which runner is configured. ## Flow completion and outstanding futures Prefect waits for submitted task runs to reach a final state before the flow run itself is finished, so a fire-and-forget submit is not silently dropped. But "not dropped" is not the same as "handled": if you never call `.result()`, the exception never propagates through your code, and your flow logic proceeds as though the work succeeded. When correctness depends on the result, resolve the future. ## Async flows If the flow and tasks are `async def`, awaiting a task call runs it concurrently under asyncio in the usual way, and the same `.submit()` mechanics remain available. Mixing sync and async carelessly is a common source of confusion — keep a flow consistently one or the other. ## Choosing between them Use a direct call when the next line needs the value anyway; the code is simpler and the traceback is more direct. Use `.submit()` when several units of work are independent and slow — the fan-out over regions, files or partitions. A pipeline where every step feeds the next gains nothing from submitting, and sprinkling `.submit()` plus an immediate `.result()` on the next line is a common anti-pattern: it reintroduces the blocking you were trying to remove while adding a layer of indirection. ## The interview shape Say the three things: direct call returns a value and blocks; `.submit()` returns a `PrefectFuture` and delegates to the task runner; futures passed as arguments become dependencies. Then add the operational nuance — failures surface at resolution time, and `wait_for` covers ordering without data.