{"record":{"id":"20fc525470b60cbf","repo":"dbt-labs/dbt-core","slug":"configuration-changes-were-identified-and-on-conf-20fc52","errorCode":null,"errorMessage":"Configuration changes were identified and `on_configuration_change` was set to `continue` for `{target_relation}`","messagePattern":"Configuration changes were identified and `on_configuration_change` was set to `continue` for `(.+?)`","errorType":"console","errorClass":null,"httpStatus":null,"severity":"warning","filePath":"crates/dbt-loader/src/dbt_macro_assets/dbt-databricks/macros/materializations/materialized_view.sql","lineNumber":44,"sourceCode":"    -- determine the scenario we're in: create, full_refresh, alter, refresh data\n    {% if existing_relation is none %}\n        {% set build_sql = get_create_materialized_view_as_sql(target_relation, sql) %}\n    {% elif full_refresh_mode or not existing_relation.is_materialized_view %}\n        {% set build_sql = get_replace_sql(existing_relation, target_relation, sql) %}\n    {% else %}\n\n        -- get config options\n        {% 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 #}\n        {% set configuration_changes = get_configuration_changes(existing_relation) %}\n\n        {% if configuration_changes is none %}\n            {% set build_sql = refresh_materialized_view(target_relation) %}\n\n        {% elif on_configuration_change == 'apply' %}\n            {% set build_sql = get_alter_materialized_view_as_sql(target_relation, configuration_changes, sql, existing_relation, None, None) %}\n        {% elif on_configuration_change == 'continue' %}\n            {% set build_sql = \"\" %}\n            {{ exceptions.warn(\"Configuration changes were identified and `on_configuration_change` was set to `continue` for `\" ~ target_relation ~ \"`\") }}\n        {% elif on_configuration_change == 'fail' %}\n            {{ exceptions.raise_fail_fast_error(\"Configuration changes were identified and `on_configuration_change` was set to `fail` for `\" ~ target_relation ~ \"`\") }}\n\n        {% else %}\n            -- this only happens if the user provides a value other than `apply`, 'skip', 'fail'\n            {{ exceptions.raise_compiler_error(\"Unexpected configuration scenario\") }}\n\n        {% endif %}\n\n    {% endif %}\n\n    {% do return(build_sql) %}\n\n{% endmacro %}\n\n\n{% macro materialized_view_execute_build_sql(build_sql, existing_relation, target_relation, post_hooks) %}\n","sourceCodeStart":26,"sourceCodeEnd":62,"githubUrl":"https://github.com/dbt-labs/dbt-core/blob/0267ce9170576975b76b64ce856b2e5848e96617/crates/dbt-loader/src/dbt_macro_assets/dbt-databricks/macros/materializations/materialized_view.sql#L26-L62","documentation":"dbt emits this warning when a materialized view's configuration changed between runs but the model's `on_configuration_change` is set to `continue`. Instead of applying (ALTER) or failing, dbt skips the rebuild entirely and just refreshes nothing, leaving the existing materialized view with its old configuration. It is raised via `exceptions.warn` in the databricks materialized_view macro.","triggerScenarios":"Running `dbt run` on a materialized view whose config (e.g. schedule, refresh, clustering keys) differs from the relation in the warehouse while the model sets `on_configuration_change='continue'` (in config block or dbt_project.yml).","commonSituations":"Teams adding or editing materialized-view properties like `mv_seed`/refresh cadence who deliberately chose 'continue' to avoid downtime, then forget the change is never applied; or inheriting configs where someone set 'continue' for CI safety.","solutions":["Change `on_configuration_change` to `'apply'` in the model config so ALTER statements run and the config change takes effect.","If the change is intended and the config drift is expected, no action is needed; the warning is informational.","If you want the run to fail loudly when config drifts, set `on_configuration_change='fail'`.","As a one-off, run the model with `--full-refresh` so the materialized view is recreated with the new configuration."],"exampleFix":"-- before\n{{ config(materialized='materialized_view', on_configuration_change='continue') }}\n-- after\n{{ config(materialized='materialized_view', on_configuration_change='apply') }}","handlingStrategy":"validation","validationCode":"# In CI, before dbt run:\nassert model_config.get('on_configuration_change') in ('apply', 'skip', 'continue', 'fail')\n# Fail the pipeline if config drift should never be ignored:\nassert model_config.get('on_configuration_change') != 'continue'","typeGuard":null,"tryCatchPattern":null,"preventionTips":["Default materialized views/streaming tables to `on_configuration_change='apply'` unless downtime is a concern.","Search dbt_project.yml and model configs for 'continue' when making config changes to incremental-like relations.","Treat this warning as config drift: verify applied DDL matches the model after every config edit."],"tags":["dbt","databricks","materialized-view","configuration"],"backgroundTag":"invalid-config-value","analyzedSha":"0267ce9170576975b76b64ce856b2e5848e96617","analyzedAt":"2026-09-07T21:53:39.732Z","contentChangedAt":"2026-09-07T21:53:39.732Z","schemaVersion":2},"datasetVersion":"2026-09-17T15:17:12.973Z"}