agent disabled store_failures and couldn't see the failed rows

TL;DR

storefailures writes failing rows to a failures schema for inspection; turning it off (or losing the config that enabled it) leaves only a count. Re-enable storefailures at the project or test level, rerun the failing tests once to populate the failures tables, and inspect the actual rows before changing any test or model.

agent disabled store_failures and couldn't see the failed rows

Use this when

• dbt tests fail and there is no failures table to query for the failing rows
• test config or dbtproject.yml previously set storefailures and it was removed or set to false
• an agent summarised failures as counts only because it could not access row detail

Not for this skill when

• your warehouse restricts creating the failures schema and you capture rows another way (for example a CI artifact query), use that path
• the tests are unit tests, which report diffs inline rather than via store_failures
• failures tables exist but are empty, that indicates the test passed at storage time or a schema mismatch instead

Steps

1. Check current config: grep dbtproject.yml, schema YAML, and test configs for storefailures values and for the tests config block that sets the failures store schema (default is the target schema with a dbttestaudit suffix pattern). Verify: you know where storefailures is set and what it currently resolves to.

2. Re-enable it deliberately: set store_failures to true for the relevant tests (project level tests config for broad capture, or per test for the noisy few). Confirm the running role can create tables in the failures schema. Verify: config enables failure storage and the role has the needed grants.

3. Rerun the failing tests with dbt test --select for the affected models so the failures tables populate for this exact failure. Verify: failures tables exist for the failing tests with the current failing rows.

4. Inspect the rows, fix the model or data, and keep store_failures on in the repo config so the next failure is debuggable by default. Verify: root cause is identified from real rows and the config change is committed.

Variant phrasings

disabled for cost or noise reasons

Failure tables for very large failing sets can be heavy. Scope store_failures to critical tests or set severity and sampling expectations instead of a global off.

dbt Cloud artifacts instead

Cloud run artifacts show failing counts but not your warehouse rows unless store_failures ran. The two are complements, not substitutes.

Compatibility: dbt-core test config store_failures (1.3 and later configuration style), failures stored in a schema derived from the target schema unless overridden. Requires create table grants in that schema.

Why it happens

A test verdict without its failing rows forces guesswork: the count says a contract broke but not which records or why. store_failures exists precisely to persist the evidence at failure time. Disabling it (often to silence noise or save a little storage) trades a tiny cost for total blindness on the next incident, which is when an agent or human most needs the rows.

Edge cases / pitfalls

• Failures tables accumulate across runs; prune them on a schedule or they become their own storage and confusion problem.
• The failures schema name differs per target, so dev captures do not prove prod capture config; check per target.
• Never share a failures table screenshot as the fix; the fix is in the model or source, the table is just evidence.

Provenance

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

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

Thread query: agent disabled store_failures and couldn't see the failed rows

TL;DR: storefailures writes failing rows to a failures schema for inspection; turning it off (or losing the config that enabled it) leaves only a count. Re-enable storefailures at the project or test level, rerun the failing tests once to populate the failures tables, and inspect the actual rows before changing any test or model.