dbt test: warn-error limit reached

Not specified by the original author.

TL;DR

You run with --warn-error and warnings count against a limit, which you hit. Either fix the warnings (they are usually real, like deprecations), or raise the limit with --warn-error-options, or drop --warn-error for the run. Do not just raise the limit forever without reading the warnings.

Error

dbt test: warn-error limit reached

Steps

1. Re-run without --warn-error and collect the actual warnings dbt prints. Expected: You see the warning list: deprecations, unused configs, or test warnings.

2. Triage the warnings: fix the ones that are real (deprecated configs, genuinely warn-severity tests), and note any that are noise. Expected: A short list of warnings worth fixing vs noise worth suppressing.

3. Fix the real ones, then either keep --warn-error with a limit that fits (--warn-error-options '{include: all, exclude: none}') or silence specific noisy warnings. Expected: The warning count drops under the limit.

4. Re-run dbt test with your original flags. Expected: Tests pass; warnings stay under the limit.

When to use

• dbt test fails with warn-error limit reached
• CI treats warnings as errors and recently started failing
• after a dbt upgrade introduced new deprecation warnings

When not to use

• tests fail with error severity on data (that is a real failure, fix the data or test)
• you never pass --warn-error (then this error cannot happen)
• the failure names a specific test, not the limit

Tool compatibility

• dbt --warn-error and --warn-error-options flags
• dbt Cloud jobs can set these flags in the job command
• warnings print in logs/dbt.log with full detail

Variant phrasings

warn-error limit reached right after upgrade

New dbt versions add deprecation warnings for old configs. Fix the deprecated configs; the warnings are the upgrade guide.

limit reached on test warnings only

Some tests warn instead of fail by severity config. Either fix the underlying data or change the test severity deliberately.

Why it happens

--warn-error turns warnings into failures so CI stays clean, and the limit caps how many it tolerates. Codebase drift (deprecations, new warnings from new tests) eventually trips the cap. The limit is a hygiene tool, not a bug.

Edge cases

• Excluding warnings to stay green defeats the purpose; exclude only after deciding the warning is truly noise.
• The warn-error options syntax changed across versions; check your dbt-core version's flag format.

Provenance

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

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

Thread query: dbt test: warn-error limit reached

TL;DR: You run with --warn-error and warnings count against a limit, which you hit. Either fix the warnings (they are usually real, like deprecations), or raise the limit with --warn-error-options, or drop --warn-error for the run. Do not just raise the limit forever without reading the warnings.

Not specified by the original author.

TL;DR

Freshness output is mostly passes; the signal is the small set of warn and error sources. Make the agent consume sources.json (or the freshness section of run results) as structured data, filter to warn and error states first, and summarize counts, instead of pasting every result into context. Page through details only for the failing sources.

agent's context filled with 900 source freshness results: couldn't find the failing model

Use this when

• an agent ran dbt source freshness over hundreds of sources and its context filled with passing results
• the agent missed or never reached the actually failing source in its summary
• freshness runs are part of an automated incident or reporting loop

Not for this skill when

• only a handful of sources exist, full output is fine and filtering is overkill
• freshness itself is misconfigured (wrong loaded_at field), fix the source config first
• you need a full audit export for compliance, generate it as a file artifact, not as agent context

Steps

1. Change the data source: have the agent read target/sources.json produced by dbt source freshness (or the equivalent artifact) with a JSON parser instead of console text. Verify: the agent consumes freshness as structured records.

2. Filter before summarizing: select only sources whose status is warn or error, plus counts of pass, and sort errors first. Bring details (source name, table, max loaded at, freshness thresholds) only for those. Verify: the agent working set is the failing and warning sources plus totals.

3. If the failing set is still large, page it: process in chunks by source grouping or schema, and write per-chunk findings to a file the agent can reference instead of holding all in context. Verify: no single step loads the full freshness detail set into context.

4. Test the workflow against a saved large sources.json: confirm the agent reports the planted error sources and correct pass counts. Verify: the agent finds every error source in the fixture without reading all passing entries.

Variant phrasings

freshness output from dbt Cloud API

The API returns the same data paginated; apply the same filter server side where possible and request only needed fields.

agent needs trend, not just failures

Keep a small rolling summary file (counts and failing names per run) rather than re-reading history; trends fit in a table, raw results do not.

Compatibility: dbt source freshness artifacts (sources.json) on dbt-core 1.x; dbt Cloud freshness API returns equivalent structured data. Context limits are a property of the agent harness.

Why it happens

Freshness checks scale linearly with source count, and their output is dominated by the uninteresting pass case. An agent that ingests raw output spends its finite context on noise in exact proportion to project size, so on a 900-source project the few error records are statistically certain to be crowded out. Filtering is not summarization flair; it is the only way the signal survives at scale.

Edge cases / pitfalls

• Do not drop warn states while filtering; warns are tomorrows errors and cheap to include.
• A freshness error can mean the check query failed, not that data is stale; keep the error message field for filtered sources.
• Keep the full sources.json as a file artifact linked from the report for audit, even though the agent never reads it whole.

Provenance

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

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

Thread query: agent's context filled with 900 source freshness results: couldn't find the failing model

TL;DR: Freshness output is mostly passes; the signal is the small set of warn and error sources. Make the agent consume sources.json (or the freshness section of run results) as structured data, filter to warn and error states first, and summarize counts, instead of pasting every result into context. Page through details only for the failing sources.

Not specified by the original author.

TL;DR

You passed --limit 0 or a negative number, or a variable feeding --limit resolved to one. Pass a positive integer like --limit 5. If the limit comes from a var, check the var value.

Error

dbt show error: limit must be positive

Steps

1. Look at your dbt show invocation and find the --limit value. Expected: You see --limit 0, a negative number, or a var reference.

2. Replace it with a positive integer: dbt show --select my_model --limit 5. Expected: The command runs and prints sample rows.

3. If the limit came from a var or env var, print its resolved value and fix the source. Expected: The variable resolves to a positive integer.

4. Re-run dbt show and confirm you get the expected row sample. Expected: Sample rows print; no limit error.

When to use

• dbt show fails with limit must be positive
• a script wraps dbt show and passes a computed limit
• the limit comes from an environment variable that is unset or zero

When not to use

• the shown query itself errors (that is a SQL problem in the model)
• you want all rows (dbt show always limits; use a warehouse query for full output)
• dbt show fails to compile the model (fix the model first)

Tool compatibility

• dbt-core 1.5+ (dbt show command)
• dbt Cloud IDE has its own preview; this is the CLI command
• --limit accepts any positive integer

Variant phrasings

limit must be positive with --limit 0

Zero is not positive. There is no way to show zero rows meaningfully; use 1 if you only want the schema.

limit error only in a wrapper script

The script computes the limit; log the computed value before calling dbt show to see the bad input.

Why it happens

dbt show compiles the model and runs it with a LIMIT clause for preview. A non-positive limit is rejected up front because the warehouse would either error or return nothing useful. The validation is protecting you from a meaningless preview.

Edge cases

• Some warehouses treat LIMIT 0 as valid SQL returning no rows; dbt rejects it anyway at the CLI layer, so do not rely on warehouse behavior.
• dbt show --inline with custom SQL validates the limit the same way.

Provenance

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

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

Thread query: dbt show error: limit must be positive

TL;DR: You passed --limit 0 or a negative number, or a variable feeding --limit resolved to one. Pass a positive integer like --limit 5. If the limit comes from a var, check the var value.