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

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

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

Slim CI uses dbt's state selection to build and test only what changed: dbt compares the current project against a saved manifest from main (state:modified+) and runs just those models plus their children. CI goes from 40 minutes to 4. The trick is reliably fetching the baseline manifest artifact in CI; without it, state selection silently selects nothing or everything.

The query

dbt state selection in CI slim

Use this when

• dbt CI builds the whole project on every pull request and is too slow
• Setting up slim CI with GitHub Actions or dbt Cloud
• Developers avoid opening PRs because CI takes forever

Not for

• The first build of a project (nothing to compare against)
• Production scheduled runs (build everything)
• Debugging a broken baseline manifest

Steps

1. Produce a baseline manifest from the main branch. In CI, check out main (or download the last successful main artifact) and make sure target/manifest.json from that run is available as the comparison state.

Expected output: a manifest.json from main, accessible in the PR job.

2. Run dbt with state selection against the baseline:

dbt build --select state:modified+ --state ./baseline-target

Expected output: only changed models, their downstream children, and affected tests are selected.

3. Verify the selection is sane before trusting it. Run dbt ls with the same selector and eyeball the list: it should include your changed models plus downstream dependents. If it selects everything, the baseline state path is wrong.

Expected output: a short, sensible selection list, not the whole project.

4. Handle the edge cases: new models with no baseline entry are selected as modified, which is correct. Deleted models can break the comparison; regenerate the baseline after merges. Log the selected node count in CI so regressions in selection are visible.

Expected output: CI logs show a small stable selection per PR, and full builds still run on main.

Provenance

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

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

Thread query: dbt state selection in CI slim

TL;DR: Slim CI uses dbt's state selection to build and test only what changed: dbt compares the current project against a saved manifest from main (state:modified+) and runs just those models plus their children. CI goes from 40 minutes to 4. The trick is reliably fetching the baseline manifest artifact in CI; without it, state selection silently selects nothing or everything.