In Airflow, what happens to the downstream tasks a BranchPythonOperator does not return?

## What the operator does `BranchPythonOperator` looks like a `PythonOperator` — it takes a `python_callable` — but Airflow interprets the return value. The callable must return a `task_id`, or a list of `task_id`s, naming tasks that are **directly downstream** of the branch task. Airflow then: 1. lets the returned task(s) follow their normal dependency rules, and 2. sets every other direct downstream task of the branch to `skipped`. Returning an id that is not a direct downstream of the branch is an error, not a silent no-op. Returning nothing skips everything downstream. ```python from airflow.operators.python import BranchPythonOperator def choose(**context): return "full_refresh" if context["data_interval_start"].day == 1 else "incremental" branch = BranchPythonOperator(task_id="choose", python_callable=choose) branch >> [full_refresh, incremental] ``` In TaskFlow the same logic is `@task.branch`, and the decorated function returns the same thing — an id or list of ids. ## Why the skip spreads Every task has a `trigger_rule`, which decides whether it may run given its upstreams' states. The default is `all_success`: run only if **every** direct upstream succeeded. A `skipped` upstream is not a success, so the dependent is skipped too. That cascade is a feature — it is what makes the unchosen branch, however long, disappear cleanly. It is also the trap. Consider a fan-in: ``` choose ──▶ full_refresh ──▶ publish └──▶ incremental ──▶ publish ``` `publish` has two upstreams. Exactly one of them will always be skipped, so under `all_success` `publish` is always skipped, and the pipeline quietly stops at the join with no failure anywhere. Every non-trivial branching DAG hits this once. ## The trigger rules that matter here - `none_failed_min_one_success` — run if no upstream failed and at least one succeeded. This is the correct join rule after a branch, and it is what you should name in an interview. (Airflow 2.2 renamed it from `none_failed_or_skipped`.) - `none_failed` — run if nothing upstream failed, tolerating all-skipped. Weaker: it will also run when every upstream was skipped. - `all_done` — run once upstreams finish regardless of outcome. Right for cleanup, wrong for a join that must not run when the real work was skipped. - `one_success`, `all_failed`, `always` — occasionally useful, rarely the branch answer. ## Sibling constructs people confuse with it - **`ShortCircuitOperator`** takes a callable returning a boolean. `False` skips *all* downstream tasks; there is no choosing between paths. Use it for "nothing to do today", not for either/or routing. - **`soft_fail=True` on a sensor** produces the same skipped state by a different route, so the same join problem appears in DAGs with no branch operator in them at all. - **`EmptyOperator`** is frequently used as the join node itself, purely to attach the trigger rule and tidy the graph. - **Dynamic task mapping** is not branching: it expands one task into N instances over a list, rather than choosing between declared paths. ## Judgment: when not to branch Branching makes a DAG graph conditional, and conditional graphs are harder to read, backfill and reason about. If the choice is small — full versus incremental parameters for the same work — a single task that reads the condition internally is often clearer than two tasks and a join. Branch when the paths genuinely differ in the tasks they run, when you want the skipped path visible in the UI, or when the two paths have different retry, alerting or resource characteristics. One more operational point: skipped is not failed, and most alerting is wired to failure. A branch bug therefore does not page anyone — the DAG run goes green with half its work skipped. If a branch guards something that must eventually happen, add an explicit check rather than trusting the absence of alerts.