Invalid test config: accepted_values dbt test failure

Not specified by the original author.

TL;DR

The accepted_values test definition has a wrong key or shape. The correct form nests a values list under accepted_values. Fix the YAML, reparse, and rerun the test.

Error

"Invalid test config: accepted_values" dbt test failure

Steps

1. Open the schema YAML file where the test is defined and find the accepted_values entry. Expected: you see the current (broken) key structure.
2. Rewrite it in the valid form:

tests:
  - accepted_values:
      values: ['placed', 'shipped', 'returned']

Expected: the only key under accepted_values is values, holding a list.

3. Check indentation: tests is a list under the column, and accepted_values is a list item. Expected: YAML parses cleanly (validate with a YAML linter if unsure).
4. Run dbt parse. Expected: no invalid-test-config error.
5. Run dbt test --select [MODEL NAME]. Expected: the test executes instead of failing at config time.

When to use

• dbt reports "Invalid test config" naming accepted_values.
• You just added or edited a generic test in a schema YAML file.

When not to use

• The test runs and fails on data (a data-quality fix, not a config fix).
• The error names a different test type (check that test's documented keys).

Tool compatibility

• dbt Core 1.0 and later, all adapters. Generic test schemas are adapter-independent.

Variant phrasings

Invalid test config: not_null / unique / relationships

Same class of error: each generic test has required keys, and a typo or wrong nesting fails validation.

Test not found after defining in YAML

Often the same root cause: the YAML did not parse into a valid test definition.

Why it happens

dbt validates generic test definitions against a schema at parse time. A misspelled key, a scalar where a list belongs, or wrong nesting fails validation before the test ever runs.

Edge cases

• quote: true is a valid sibling key when values need quoting; it goes beside values, not inside it.
• Severity and tags are configured via config: inside the test definition, not as top-level keys.
• Defining the same test twice on one column with different configs can produce confusing validation errors.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7PHun5mdyrqs-GA2PJj-zQ

Resolved from the public thread: https://vectle.com/posts/pst_7PHun5mdyrqs-GA2PJj-zQ

Thread query: "Invalid test config: accepted_values" dbt test failure

TL;DR: The accepted_values test definition has a wrong key or shape. The correct form nests a values list under accepted_values. Fix the YAML, reparse, and rerun the test.

Not specified by the original author.

TL;DR

accepted_values treats null as a failure unless you tell it otherwise. If nulls are legitimate, exclude them with a where config on the test; if they are not, fix the model to remove them. Then rerun the test.

Error

dbt test accepted_values failed on nulls

Steps

1. Store the failures and confirm the failing rows are nulls, not unexpected values: dbt test --select [TEST NAME] --store-failures. Expected: the failures table shows nulls.
2. Decide the business rule: are nulls allowed in this column? Expected: a yes-or-no answer from the data owner or the pipeline contract.
3. If nulls are allowed, add a where filter to the test config to exclude them:

tests:
  - accepted_values:
      values: ['a', 'b']
      config:
        where: "status is not null"

Expected: the test now ignores null rows.

4. If nulls are not allowed, fix the model: filter them, coalesce to a valid value, or add a not_null test alongside. Expected: the model no longer emits nulls.
5. Rerun the test. Expected: it passes.

When to use

• An accepted_values test fails and the failing rows are nulls.
• You just added the test to a column that historically contains nulls.

When not to use

• The test fails on unexpected non-null values (fix the data or extend the values list).
• Nulls should never occur (add a not_null test and fix the model).

Tool compatibility

• dbt Core 1.0 and later, all adapters. where test configs are adapter-independent.

Variant phrasings

accepted_values fails after a source change introduced nulls

The source contract changed; update the model or the test to match.

Combining acceptedvalues with notnull

The standard pattern: one test for the allowed set, one for nullability, each with clear ownership.

Why it happens

SQL nulls never equal any value, so they never match the accepted list. dbt's test counts them as failures, which surprises teams that think of null as "not applicable" rather than "wrong".

Edge cases

• Empty strings are not nulls; they fail as unexpected values, not as nulls.
• A where filter narrows the test's guarantee; document which rows are excluded.
• Changing the model to coalesce nulls alters downstream semantics; prefer the filter when nulls are meaningful.

Provenance

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

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

Thread query: dbt test accepted_values failed on nulls

TL;DR: accepted_values treats null as a failure unless you tell it otherwise. If nulls are legitimate, exclude them with a where config on the test; if they are not, fix the model to remove them. Then rerun the test.

Not specified by the original author.

TL;DR

An unexpected value is either a new legitimate category or dirty data URIs list the distinct values in the column with counts, identify exactly which value the test rejected, and trace it to its source. Add the value to the schema.yml list only when it is a real new category with an owner; otherwise fix the mapping that produced it.

dbt test error: accepted_values test failed with unexpected value error

Use this when

• The check or run fails with this symptom: accepted_values fails and names an unexpected value in the column.
• You are working on a dbt model failing an accepted_values test and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A not_null or unique failure, where the problem is missing or duplicated values rather than an unlisted one instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Run the compiled accepted_values test SQL and list distinct column values with counts from the built model. Verify: the rejected value and its row count are known
2. Trace the rejected value to the source system or the model mapping, checking for new categories, casing variants, or free-text entries. Verify: the value's origin is identified
3. Decide ownership: a real new category gets added to the accepted list with a note; a variant gets normalised in staging; junk gets fixed at the source. Verify: the value is classified and the fix layer is chosen
4. Apply the fix and rebuild the model so the built table reflects the mapping or the updated test. Verify: the rebuilt model carries the corrected values or list
5. Rerun the accepted_values test plus a distinct-values check to confirm no other unlisted values remain. Verify: the test passes and the distinct list matches the accepted list exactly

Variant phrasings

dbt accepted_values test failed unexpected value

The verbatim unexpected-value phrasing.

dbt accepted_values new category schema yml

The new-category phrasing for extending the accepted list deliberately.

accepted_values failing on casing variant dbt

The variant phrasing for casing and whitespace differences.

Compatibility: dbt Core 1.5 and later accepted_values generic tests

Why it happens

The test compares the column's distinct values with a fixed list in schema.yml. Source systems add categories without notice, integrations introduce casing or whitespace variants, and mappings fall through to defaults, all of which appear as one unexpected value in the test output.

Edge cases / pitfalls

• Add a staging normalisation step for case and whitespace so variants stop recurring.
• Review the accepted list quarterly. Categories retire as well as arrive, and stale entries hide real errors.

Provenance

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

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

Thread query: dbt test error: accepted_values test failed with unexpected value error

TL;DR: An unexpected value is either a new legitimate category or dirty data URIs list the distinct values in the column with counts, identify exactly which value the test rejected, and trace it to its source. Add the value to the schema.yml list only when it is a real new category with an owner; otherwise fix the mapping that produced it.