[v2 Bug] No error when a `state:` selector runs without a comparison manifest

[Kiyoshi09]

Is this a new bug in dbt v2.x compared to the latest version of dbt 1.x?

• I believe this is a new bug in dbt v2.x
• I have searched the existing issues and could not find a duplicate

Current Behavior

When a selector uses a state: method and no comparison manifest is available, Fusion does not raise an error or a warning. The run continues and reports success.

Because nothing stops the run, a state: selector can trigger a build of every model and snapshot in the project. Nothing in the output indicates that the selector did not work as intended.

dbt Core refuses to run in the same situation.

Expected Behavior

Return an error when a state: method is evaluated with no comparison manifest, matching dbt Core.

Running the same project and the same selector under dbt Core 1.11.11 stops immediately:

02:50:25  Running with dbt=1.11.11
02:50:25  Registered adapter: snowflake=1.12.0-b1
02:50:26  Found 5 models, 1 snapshot, 6 sources, 660 macros
02:50:26  Encountered an error:
Runtime Error
  Got a state selector method, but no comparison manifest

Erroring is safer than proceeding, because the current failure mode is silent and expensive.

Steps To Reproduce

Minimal project: 5 models, 1 snapshot, 6 sources.

selectors.yml:

selectors:
  - name: release_main
    definition:
      union:
        - method: state
          value: "new"
          children: true
        - method: state
          value: "modified.body"
          children: true

1. Build once and capture a baseline manifest

dbt build
mkdir -p ./state_baseline && cp target/manifest.json ./state_baseline/

2. Control: --state supplied, nothing changed

dbt ls --selector release_main --state ./state_baseline

==> 0 nodes selected. Correct.

3. Control: --state supplied, after editing one staging model

Edit any staging model, then run the same command.

dbt ls --selector release_main --state ./state_baseline

==> The edited model and its single downstream model. Correct.

Revert the edit before continuing.

4. Defect: no --state

dbt build --selector release_main

==> Every node in the project is built. No error, no warning.

5. The same project and selector under dbt Core 1.11.11

dbt ls --selector release_main --no-partial-parse

==> Runtime Error
  Got a state selector method, but no comparison manifest

Failure mode by method

Isolating each method, with no --state:

- name: only_new
  definition:
    method: state
    value: "new"

- name: only_modified
  definition:
    method: state
    value: "modified"

dbt ls --selector only_new

==> All 12 nodes.

dbt ls --selector only_modified

==> 0 nodes.

Neither produces an error or a warning.

Relevant log output

Without `--state`, the selector returns every node in the project:

$ dbt ls --selector release_main

dbt-fusion 2.0.0-preview.209
=========================Selected nodes=========================
state_repro.marts.customer_orders
state_repro.marts.product_summary
state_repro.staging.stg_customers
state_repro.staging.stg_orders
state_repro.staging.stg_products
state_repro.orders_snapshot.orders_snapshot
source:state_repro.jaffle_shop.customers
source:state_repro.jaffle_shop.items
source:state_repro.jaffle_shop.orders
source:state_repro.jaffle_shop.products
source:state_repro.jaffle_shop.stores
source:state_repro.jaffle_shop.supplies

=========================== Execution Summary ===========================
Finished 'list' successfully for target 'dev' [1.3s]



With `--state` supplied and one staging model edited, the same selector returns only what changed:

$ dbt ls --selector release_main --state ./state_baseline

dbt-fusion 2.0.0-preview.209
=========================Selected nodes=========================
state_repro.marts.customer_orders
state_repro.staging.stg_customers

=========================== Execution Summary ===========================
Finished 'list' successfully for target 'dev' [1.1s]

Environment

- OS: macOS
- dbt Fusion: 2.0.0-preview.209
- dbt Core: 1.11.11 with dbt-snowflake 1.12.0-b1 (for the contrasting behavior)

Which database adapter are you using?

No response

Is this a discrepancy vs. dbt 1.x?

• Yes — this works in dbt 1.x but not in dbt v2.x

Additional Context

No response