dbt state:modified bug: comparing wrong artifacts

Not specified by the original author.

TL;DR

state:modified compares the current project against the manifest in the --state directory. If that directory holds the wrong artifacts (a different target, an old run), the selection is wrong. Point --state at the right prior manifest, verify with dbt ls, then run.

Error

dbt state:modified bug: comparing wrong artifacts

Steps

1. Check what is in your --state directory: look at the manifest.json timestamp and the target it was built from. Expected: you confirm whether it matches the baseline you intended.
2. Point --state at the correct artifacts, for example the prod manifest: dbt ls --select state:modified --state path/to/prod-artifacts. Expected: the command uses the intended baseline.
3. Inspect the selection: does it match the models you actually changed? Expected: the selected set looks right.
4. If the selection is still wrong, rebuild the baseline manifest from the correct branch and target, then retry. Expected: a fresh, trustworthy baseline.
5. Run your command with the corrected --state path. Expected: only truly modified models (and their children, if selected) run.

When to use

• state:modified selects models you did not change, or misses ones you did.
• You just changed how CI stores or fetches artifacts.

When not to use

• State selection works but is slow (an artifact-size problem).
• You want all models (drop the state selector entirely).

Tool compatibility

• dbt Core 1.0 and later, all adapters. State selectors are adapter-independent.

Variant phrasings

state:modified selects everything on every run

The baseline manifest is stale or from a different target; every node looks modified.

state:new misses a new model

The baseline is newer than you think, or the model was not in the baseline manifest.

Why it happens

State comparison is only as good as the baseline. A manifest from the wrong target, branch, or era makes the diff meaningless, and dbt faithfully reports the wrong diff.

Edge cases

• Manifests are not portable across dbt versions; a baseline built with a different core version can misbehave.
• Partial parsing can make the current side of the diff stale; use --no-partial-parse when debugging selection.
• In CI, download the baseline artifacts before running dbt; a missing --state dir fails the run.

Provenance

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

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

Thread query: dbt state:modified bug: comparing wrong artifacts

TL;DR: state:modified compares the current project against the manifest in the --state directory. If that directory holds the wrong artifacts (a different target, an old run), the selection is wrong. Point --state at the right prior manifest, verify with dbt ls, then run.

Not specified by the original author.

TL;DR

State selection compares against a saved manifest from a previous production run, and dbt cannot find it at the --state path you gave (or you gave none). Download or mount the production manifest.json into a state folder, pass --state pointing at it, and rerun. Without a baseline manifest there is nothing to compare, so the run stops by design.

dbt run --select state:modified: no state comparison artifacts found

Use this when

• dbt run --select state:modified fails saying no state comparison artifacts found
• you are setting up slim CI or a deferred job for the first time
• the state folder is empty, gitignored, or produced by a job that stopped uploading it

Not for this skill when

• state selection runs but includes too much or too little, that is baseline freshness or selection syntax instead
• you want a full run, drop the state selector rather than fabricating a baseline
• the baseline exists but is from a different project, regenerate it from this project prod run

Steps

1. Locate where your production job writes artifacts: in dbt Cloud, download the manifest.json from the latest successful prod run; for self-hosted runs, find the target folder the prod pipeline archives. Verify: you have a real prod manifest.json file in hand.

2. Place it in a dedicated folder such as state/manifest.json (its own folder, not mixed into the current target/), and make sure CI checks it out or downloads it before the dbt step. Verify: the state folder contains manifest.json before dbt runs.

3. Run dbt ls --select state:modified --state state/ first to preview the selection without building. Confirm the listed models match a recent change you made. Verify: the preview lists the expected changed models and their children if you add the plus suffix.

4. Run the real command with the same --state path, for example dbt run --select state:modified+ --state state/. Verify: the run builds the selected models and completes.

Variant phrasings

first ever slim CI run

There is no baseline until prod runs once with artifact saving on. Bootstrap by running one full prod build that archives manifest.json, then enable state selection.

artifacts found but stale

An old baseline makes state:modified select nearly everything. Refresh the baseline on every successful prod run, not weekly.

Compatibility: dbt-core state selection, 1.x; --state expects a folder containing manifest.json from a prior run of the same project. dbt Cloud exposes run artifacts for download via the API and UI.

Why it happens

state:modified is a diff, and a diff needs two sides. dbt loads the comparison manifest only from the --state directory; it does not fall back to target/ or to dbt Cloud history automatically. When that directory is missing or empty, dbt reports that no state artifacts were found instead of guessing a baseline.

Edge cases / pitfalls

• Never use a dev manifest as the prod baseline; schema and config differences pollute the diff.
• Resource changes like a renamed column count as modified config in some versions; expect slightly wide selections after YAML-heavy changes.
• Keep the baseline manifest out of the repo if it contains environment details your policy excludes; fetch it in CI instead.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst7uy-7sDBCXyjRVevXWyyA

Resolved from the public thread: https://vectle.com/posts/pst7uy-7sDBCXyjRVevXWyyA

Thread query: dbt run --select state:modified: no state comparison artifacts found

TL;DR: State selection compares against a saved manifest from a previous production run, and dbt cannot find it at the --state path you gave (or you gave none). Download or mount the production manifest.json into a state folder, pass --state pointing at it, and rerun. Without a baseline manifest there is nothing to compare, so the run stops by design.

Not specified by the original author.

TL;DR

dbt clone compares your current manifest against the --state manifest, and they disagree about what is the same. Regenerate the state artifacts from the same commit and target, point --state at that directory, and re-run. Mixing artifacts from different branches or targets is the usual cause.

Error

dbt clone failed: state artifact mismatch

Steps

1. Check what --state points at and when its manifest.json was generated (look at generated_at inside the file). Expected: You see whether the state manifest is stale, from another branch, or built for a different target.

2. Regenerate state cleanly: check out the reference commit, run dbt compile (or parse) with the same target, and copy the resulting target/ aside as your state directory. Expected: A fresh state manifest from the right commit and target.

3. Re-run dbt clone --state path/to/fresh/state. Expected: State comparison succeeds and clone proceeds.

4. If it still mismatches, diff the two manifests' node counts; a model added or removed between state generation and now explains it. Expected: You find the added or removed node and regenerate state after the change.

When to use

• dbt clone fails with state artifact mismatch
• state artifacts were copied from a different branch or target
• CI generates state in one job and clones in another with different checkouts

When not to use

• clone fails with a permission error on the source schema (that is grants, not state)
• the source schema or tables do not exist (nothing to clone)
• you are not using deferral or cloning at all

Tool compatibility

• dbt-core 1.1+; dbt clone --state is the deferral workflow
• manifest.json generated_at tells you when state was built
• CI: persist the state directory as an artifact between jobs

Variant phrasings

state artifact mismatch in slim CI

Slim CI lives on this mechanism: --select state:modified --state prod_artifacts. The prod artifacts must come from the production job's target/, same dbt version.

mismatch after dbt upgrade

Manifest schema versions differ across dbt versions. Regenerate state with the same dbt version you clone with.

Why it happens

State comparison is a manifest-to-manifest diff. If the two manifests were built from different code, different targets, or different dbt versions, the diff is meaningless and dbt refuses rather than cloning the wrong things. Fresh, matched artifacts are the fix.

Edge cases

• dbt Cloud deferral handles state internally; this error is mostly a CLI/CI concern.
• Deferral to another environment also needs the right target in the state manifest, not just the right commit.

Provenance

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

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

Thread query: dbt clone failed: state artifact mismatch

TL;DR: dbt clone compares your current manifest against the --state manifest, and they disagree about what is the same. Regenerate the state artifacts from the same commit and target, point --state at that directory, and re-run. Mixing artifacts from different branches or targets is the usual cause.