agent's dbt test run blocked on unrelated failure: selector scoping

TL;DR

The agent runs dbt across the whole project, one unrelated model fails, and the agent's actual change never gets validated. Scope the run to the changed model and its downstream with selectors, exclude known-broken nodes explicitly, and log the scoping decision. The agent should validate its change, not fix the entire project.

Symptom

The agent runs dbt build or dbt test on the full project, an unrelated model fails, and everything after it is skipped or the run exits non-zero. The agent then either tries to fix a model it did not break, or reports its own change as untestable. Either way the real change never gets a clean validation.

Steps

1. Identify the failing node and confirm it is unrelated: check whether it or its upstream is in the agent's change set.

Expected output: a named node with no dependency link to the agent's change. If it IS related, fix the model, not the scoping.

2. Scope the run to the agent's change and its downstream with selectors:

dbt build --select my_model+ --exclude tag:known_broken

Expected output: only the changed model and its children build and test. The unrelated failure is out of scope and cannot block the run.

3. For test-only validation, run tests per model so one failure does not mask the rest:

dbt test --select my_model+

Expected output: test results for the in-scope models regardless of out-of-scope breakage.

4. Record the scoping decision in the run log: what was selected, what was excluded, and why. Review exclusions regularly so a tag like known_broken does not become permanent.

Expected output: an auditable run a human can reproduce, plus a cleanup list for the excluded nodes.

When to use

• dbt test or dbt build fails on a model the agent did not touch
• An agent's change cannot get validated because the project has pre-existing failures
• CI runs the full project and one flaky model blocks merges

When not to use

• The failure is in the agent's changed model or its upstream (fix the model)
• The project is green and the agent just needs to run the suite (run it all)
• The failure is environmental (warehouse down, credentials); scoping will not help

Variant phrasings

agent keeps trying to fix unrelated failing models

Give the agent the scoped selector as part of its instructions, not as a suggestion. Agents follow the command they are given.

full build passes but the agent's model was skipped

Something upstream of the agent's model failed silently or was excluded. Check the run graph for skipped nodes, not just failures.

Why it happens

dbt's default is whole-project runs, which is correct for CI but wrong for an agent validating a scoped change. One pre-existing failure anywhere in the graph poisons the run, and the agent has no notion of "not my problem" unless the invocation tells it. Selectors are how you draw that boundary.

Edge cases

• my_model+ includes downstream children; use +my_model+ when the change needs its upstream rebuilt too.
• Excluding by tag requires the tag to exist on the broken models; an exclusion that matches nothing silently does nothing.
• state:modified selectors compare against a manifest artifact; make sure the agent has a fresh manifest or the selection is empty.

Provenance

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

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

Thread query: agent's dbt test run blocked on unrelated failure: selector scoping

TL;DR: The agent runs dbt across the whole project, one unrelated model fails, and the agent's actual change never gets validated. Scope the run to the changed model and its downstream with selectors, exclude known-broken nodes explicitly, and log the scoping decision. The agent should validate its change, not fix the entire project.