In dbt, why does dbt build skip downstream models on a test failure when dbt run then dbt test does not?

## Two execution shapes `dbt run` and `dbt test` are *phase-ordered*. `dbt run` selects the model nodes and executes them in dependency order until every model is built. `dbt test` then selects the test nodes and executes those. Nothing about the first phase consults the second. If a staging model produced duplicate primary keys tonight, the fact table, the aggregate and the mart every dashboard reads were all built on those duplicates before the first test ran. `dbt build` is *graph-ordered* across node types. It builds one combined DAG containing seeds, snapshots, models and tests, then executes it in dependency order. Because a generic test declared on `stg_orders` has `stg_orders` as its parent, and `fct_orders` also has `stg_orders` as a parent, the scheduler runs the model, then its tests, then — only if those passed — the downstream model. ```text seed raw_countries | stg_orders -> [unique_stg_orders_order_id, not_null_stg_orders_order_id] | | +------------------------+---> fct_orders -> [tests on fct_orders] | mart_revenue ``` When `unique_stg_orders_order_id` errors, `fct_orders` and `mart_revenue` are reported as **skipped**, not failed. The distinction matters in the summary: skipped means dbt chose not to attempt it because an ancestor was unhealthy. ## What that buys you The practical value is blast radius. With `run` then `test`, the bad data is in production and your options are to roll back or to publish a caveat. With `build`, the last known-good version of `fct_orders` is still what consumers see, because tonight's version was never written. A stale mart is almost always better than a wrong one, and "stale but correct" is exactly the trade-off `dbt build` encodes. ## The catch: tests must be positioned in the graph The guarantee comes entirely from dependencies. A generic test declared in YAML always has the right parent. A singular test that hardcodes `analytics.stg_orders` instead of `{{ ref('stg_orders') }}` has *no* parents, so dbt is free to run it at any point — quite possibly before the model it checks is rebuilt. This is the most common reason a team believes `dbt build` protected them when it did not. ## Indirect selection When you run `dbt build --select fct_orders`, which tests come along? dbt's default `--indirect-selection` mode is `eager`: it includes any test that touches the selected node, even if the test also references models outside the selection. `cautious` includes only tests whose every parent is in the selection — safer when you are building a subset and do not want tests failing because of an unselected, unbuilt neighbour. `buildable` sits in between. Knowing this flag exists is a genuine seniority signal, because it explains the confusing case of "my subset build failed on a test about a model I did not select". ## Other flags that shape a failing run - `--fail-fast` (`-x`) aborts the whole invocation on the first failure rather than continuing with unrelated branches. Good for CI, bad for a nightly run where you want the independent branches to finish. - `--warn-error` promotes warnings to errors, which combined with `build` means a warn-severity test now also skips downstream models. - `--exclude` lets you drop a known-failing test to unblock a single incident run. - `dbt retry` re-runs the previous invocation from the point of failure using `run_results.json`, so you do not rebuild the hours of work that already succeeded. ## What build covers that run does not `dbt build` is not only "run plus test". It also executes **seeds** (as `dbt seed` would) and **snapshots** (as `dbt snapshot` would), in graph order. That matters because a snapshot must capture source state *before* the models that read it are rebuilt, and a seed feeding a lookup must load first. Teams that scripted `dbt seed && dbt snapshot && dbt run && dbt test` in a shell were approximating build with a fixed phase order; `build` derives the order from the actual graph. ## When run and test separately is still right Development. Iterating on one model, you often want `dbt run --select my_model` repeatedly and to test only when you are ready. Some teams also keep them separate when they deliberately want the full build to complete so they can inspect everything, accepting bad data in a dev schema. In production, though, `dbt build` is the default answer and saying otherwise needs a reason.