dbt-labs/dbt-core · warning

No configuration changes were identified on: `{{ target_rela

Error message

No configuration changes were identified on: `{{ target_relation }}`. Continuing.

What it means

This is a warning emitted by the Snowflake interactive table materialization when dbt detects no configuration changes between the model's rendered config and the existing interactive table. The materialization short-circuits with an empty build_sql and warns via `exceptions.warn` instead of issuing any DDL. It is informational: nothing is wrong, dbt just found no ALTER to perform.

Source

Thrown at crates/dbt-loader/src/dbt_macro_assets/dbt-snowflake/macros/materializations/interactive_table.sql:45

-- funcsign: (optional[relation], relation) -> string
{% macro interactive_table_get_build_sql(existing_relation, target_relation) %}

    {% set full_refresh_mode = should_full_refresh() %}

    {#- determine the scenario we're in: create, full refresh, alter -#}
    {% if existing_relation is none %}
        {% set build_sql = get_create_sql(target_relation, sql) %}
    {% elif full_refresh_mode or not existing_relation.is_interactive_table %}
        {% set build_sql = get_replace_sql(existing_relation, target_relation, sql) %}
    {% else %}

        {#- get config options -#}
        {% set on_configuration_change = config.get('on_configuration_change', 'apply') %} {# DIVERGENCE: core does not default to `apply` here because it sets it elsewhere in the Python code #}
        {% set configuration_changes = snowflake__get_interactive_table_configuration_changes(existing_relation, config) %}

        {% if configuration_changes is none %}
            {% set build_sql = '' %}
            {{ exceptions.warn("No configuration changes were identified on: `" ~ target_relation ~ "`. Continuing.") }}

        {% elif on_configuration_change == 'apply' %}
            {% set build_sql = snowflake__get_alter_interactive_table_as_sql(existing_relation, configuration_changes, target_relation, sql) %}
        {% elif on_configuration_change == 'continue' %}
            {% set build_sql = '' %}
            {{ exceptions.warn("Configuration changes were identified and `on_configuration_change` was set to `continue` for `" ~ target_relation ~ "`") }}
        {% elif on_configuration_change == 'fail' %}
            {{ exceptions.raise_fail_fast_error("Configuration changes were identified and `on_configuration_change` was set to `fail` for `" ~ target_relation ~ "`") }}

        {% else %}
            {#- this only happens if the user provides a value other than `apply`, 'continue', 'fail' -#}
            {{ exceptions.raise_compiler_error("Unexpected configuration scenario: `" ~ on_configuration_change ~ "`") }}

        {% endif %}

    {% endif %}

    {% do return(build_sql) %}

View on GitHub (pinned to 0267ce9170)

Solutions

  1. No action needed if the table is up to date — the run continues and build_sql is empty by design
  2. If you expect changes to be detected, verify the model config values actually differ from the existing relation (SHOW INTERACTIVE TABLE / DESCRIBE)
  3. If the state comparison is wrongly returning none, check that the relation exists in the cache and wasn't dropped out-of-band
Defensive patterns

Strategy: validation

Validate before calling

// verify the existing relation's config matches the model config before running
// e.g. compare target_lag/warehouse against SHOW INTERACTIVE TABLE output
const drift = compareRelationConfig(existingRelation, modelConfig);
if (drift.length === 0) {
  console.log('No config drift; warning is expected and harmless.');
}

Prevention

When it happens

Trigger: Running `dbt run` on a Snowflake model materialized as interactive_table where `snowflake__get_interactive_table_configuration_changes(existing_relation, config)` returns none, meaning every config option (cluster_by, automatic_clustering, etc.) matches the existing relation.

Common situations: Re-running a model with unchanged config after a previous build; misreading the warning as an error when the table is actually already up to date.

Understand the failure class

Background: "Invalid state transition" errors: "status must be X, actually Y", "already rejected/charging/uninstalled", "cannot ... while running" — what they mean when a library rejects your call — this error's family across 31 libraries.

Related errors

AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07). Data as JSON: /api/errors/bed763ecfd6b4deb. Report an issue: GitHub.