In Airflow's TaskFlow API, how does calling one @task function inside another build the DAG?

## Two things happen at once The TaskFlow API's whole trick is that a function call in a DAG file expresses two facts simultaneously: *b depends on a*, and *b consumes a's output*. In the classic style those are separate lines — an arrow plus an `xcom_pull` inside the callable — and they drift apart. TaskFlow collapses them. ```python @task def extract() -> list[dict]: return fetch_orders() @task def transform(orders: list[dict]) -> int: return sum(o["total"] for o in orders) @task def load(total: int) -> None: write_metric(total) load(transform(extract())) ``` ## What actually happens at parse time When the file is parsed, `@task` has already turned each function into a callable factory backed by a Python-operator-style task. Calling `extract()` therefore does **not** invoke `fetch_orders()` in the parsing process. It constructs the task with `task_id="extract"` and returns an `XComArg` — an object meaning "whatever the extract task returns, once it has run". Passing that `XComArg` into `transform(...)` does two things: it records `extract` as an upstream of `transform`, and it stores, in the serialized task, the instruction to resolve that argument by pulling extract's XCom at run time. On the worker, the operator resolves each `XComArg` argument to a concrete value and only then calls your function body. This is why the dependency and the data path can never disagree — they come from the same expression. A consequence worth stating explicitly in an interview: the values inside your functions are real Python values *at run time*, but the expression in the DAG file manipulates placeholders *at parse time*. You cannot branch on an `XComArg` in the DAG body — `if extract() > 10:` is meaningless, because the parser is holding a reference, not a number. Run-time decisions need `@task.branch` or a short-circuit task. ## Return values, keys, and multiple outputs A TaskFlow function's return value is pushed to XCom under the key `return_value`. Return `None` and nothing useful is pushed. If you need to hand different fields to different downstream tasks, use multiple outputs: ```python @task(multiple_outputs=True) def split() -> dict: return {"path": "s3://bucket/f.parquet", "rows": 1200} out = split() load_file(out["path"]) report(out["rows"]) ``` Each dict key becomes its own XCom entry, so `load_file` depends on `split` but only pulls the `path` value. Annotating the function `-> dict` sets `multiple_outputs` implicitly. ## Calling the same function twice Task ids must be unique within a DAG. Calling `extract()` twice raises a duplicate-id error unless you disambiguate, either with `extract.override(task_id="extract_eu")()` or by mapping (see dynamic task mapping). This surprises people who think of the decorated object as an ordinary function they can reuse freely. ## Mixing with classic operators TaskFlow is not an alternative universe. Every operator instance exposes `.output`, which is the same `XComArg` type, so a classic operator feeds a TaskFlow function directly: ```python query = SQLExecuteQueryOperator(task_id="query", sql="select count(*) from orders", conn_id="dw") summarise(query.output) ``` And when there is no data to pass, plain arrows still work: `wait_for_file >> extract()`. Related decorators cover the common operator flavours — `@task.branch` for branching, `@task.short_circuit`, `@task.bash`, `@task.virtualenv` and `@task.docker` for isolated execution environments. ## The trap: it is still XCom The ergonomics make it feel like ordinary function composition, so people return whole pandas DataFrames. Those get serialised into the metadata database on every run, bloating it and eventually failing on the storage backend's limits. The discipline is unchanged from classic XCom usage: pass identifiers and paths, write payloads to object storage, or configure a custom XCom backend that transparently offloads the value and stores a pointer. Also remember that XComs are scoped to a DAG run — a task cannot read yesterday's run's value just by taking an argument. ## Why interviewers like this question It separates people who have *used* TaskFlow from people who understand what the DAG file is: a program that builds a graph, not a program that processes data. Saying "calling the function returns a lazy reference, and the parser never runs the body" is the answer that lands.