## TL;DR

The model built fine; the data or the test definition is wrong. Run the failing test alone with dbt test --select, look at the failing rows dbt returns, and decide: fix the data upstream, or fix the test config. Do not rebuild the model, it is innocent.

## Error

```text
dbt build failed on test after model succeeded
```

## Steps

1. Run dbt test --select the_failing_test to isolate it, and set --store-failures if configured so you can query the offending rows.
   Expected: The test fails alone, and you can see the failing row sample.

2. Inspect the failing rows: are they real data problems (null keys, dupes, bad values) or is the test misconfigured (wrong column, too-strict accepted_values)?
   Expected: You can classify it as data bug vs test bug.

3. Data bug: fix the model or the source that produced the rows, then rebuild. Test bug: correct the test config in schema.yml (right column, right values, right severity).
   Expected: The underlying cause is addressed, not just the symptom.

4. Re-run dbt build --select the_model+ to rebuild the model and its tests together.
   Expected: Model and tests both green.

## When to use

- dbt build fails on a test while the model itself succeeded
- a new test was just added and immediately fails
- tests fail after a source data change, not a model change

## When not to use

- the model itself fails to build (fix the model SQL first)
- the test errors with a SQL error rather than failing rows (that is a test definition bug)
- you want to run only tests without models (use dbt test, not dbt build)

## Tool compatibility

- dbt build runs models then tests in dependency order
- --store-failures persists failing rows to the warehouse for inspection
- dbt Cloud shows per-test failure output in the run logs

## Variant phrasings

### build failed on a relationships test
The child has keys missing from the parent. Either the parent model is stale (rebuild it first) or the child genuinely has orphans (fix the join or the source).

### build failed right after adding a generic test
New tests often encode wrong assumptions about the data. Check the test config before assuming the data is bad.

## Why it happens

dbt build is model-then-test by design, so a green model with a red test means the SQL ran but the data contract broke. The model is usually fine; the test is doing its job and pointing at data or at its own config.

## Edge cases

- warn-severity tests do not fail the build; if the build failed, the test severity is error (or warn-error is on), check the config.
- Stale parent models cause phantom test failures; dbt build rebuilds in order, but a --select subset can test against stale parents.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_a25nzI5rIvp5_2MQ_lJEDw