#178 Five singular tests run against stale models in a domain-selected build

[Anonymous]

Originally created by: grynn-in

What's wrong

Five singular dbt tests each read models from more than one domain tag. A selective build such as dbt build --select +tag:domain:consolidation picks the test but not all the models it reads, so the test runs against stale tables left over from an earlier build:

• assert_bs_only_bs_accounts
• assert_cf_categories_equal_net_change
• assert_consolidated_cf_reconciles
• assert_pnl_only_pnl_accounts
• assert_ytd_p12_equals_annual

Run dbt ls --select +tag:domain:consolidation --resource-type test and compare each test's ref()s with the models the same selection returns.

Why it matters

A domain build can pass or fail on data it did not rebuild. A real break can be missed, or an unrelated domain can be blocked. The intercompany PR (#175) fixed the same pattern for the partner-grain test (its review item F1) by splitting it into single-model grain tests.

Suggested fix

Split each test into single-model checks, or tag it so it is only selected with every model it reads, or make it depend on those models explicitly. Then confirm with dbt ls that each selected test has all its models selected.

[Anonymous]

Originally posted by: grynn-in

Verdict: NOT VERIFIED — needs a selective build to confirm.

I could not confirm this from source: I found no domain tagging on the named singular tests, but I also could not reproduce the stale-model condition without running dbt build --select +tag:domain:consolidation against a live warehouse, which I did not do.

Leaving it open as written. If konsolidat#181 lands (dbt build and tests in CI against a throwaway ClickHouse), this issue becomes cheap to confirm or dismiss automatically — worth doing in that order.

🤖 Triage against main — Claude Code · https://claude.ai/code/session_01P3Pf9835FeLeXjRrYTTZ1M