dbt-labs/dbt-core · error

resolve_file_format is only supported in Databricks

Error message

resolve_file_format is only supported in Databricks

What it means

resolve_file_format returns the model's file_format warehouse config, defaulting to 'delta' for Databricks (dbt-databricks impl.py#L994). Unlike its siblings it uses a catch-all `_ =>` arm that panics with unimplemented!(), so every non-Databricks adapter type — including future adapter variants — hits the panic when this is called.

Source

Thrown at crates/dbt-adapter/src/adapter/adapter_impl.rs:4530

        }
    }

    /// When config omits file_format, falls back to this adapter's default (Databricks
    /// defaults to "delta"). Used by clone materialization.
    ///
    /// DatabricksAdapter https://github.com/databricks/dbt-databricks/blob/2f11abb306a400cde32b27891b766bf41a11fb1f/dbt/adapters/databricks/impl.py#L994
    pub fn resolve_file_format(&self, config: ModelConfig) -> AdapterResult<String> {
        match self.adapter_type() {
            Databricks => {
                let file_format = config
                    .__warehouse_specific_config__
                    .file_format
                    .as_deref()
                    .unwrap_or("delta")
                    .to_string();
                Ok(file_format)
            }
            _ => unimplemented!("resolve_file_format is only supported in Databricks"),
        }
    }

    /// Given a relation, fetch its configurations from the remote data warehouse
    ///
    /// DatabricksAdapter https://github.com/databricks/dbt-databricks/blob/7c282cabb518a5e1173222e7901896d31de8401f/dbt/adapters/databricks/impl.py#L1088
    pub fn get_relation_config(
        &self,
        state: &State,
        conn: &mut dyn Connection,
        relation: &Arc<dyn BaseRelation>,
        model_config: Option<&RelationConfig>,
        token: CancellationToken,
    ) -> AdapterResult<RelationConfig> {
        use crate::relation::databricks::config::relation_types;

        if let Replay(_, replay) = self.inner_adapter()
            && let Some(recorded) = replay.replay_get_relation_config(state)?

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Guard with adapter.type() == 'databricks' and use a platform-appropriate default (or the model's own file_format config) elsewhere
  2. Keep resolve_file_format calls inside Databricks-only materialization branches
  3. Verify the active dbt target is Databricks when running models that rely on delta file formats

Example fix

{% if adapter.type() == 'databricks' %}
  {% set file_format = adapter.resolve_file_format(config) %}
{% else %}
  {% set file_format = config.get('file_format', 'default') %}
{% endif %}
Defensive patterns

Strategy: type-guard

Validate before calling

{% if adapter.type() == 'databricks' %}
  {% set file_format = adapter.resolve_file_format(config) %}
{% endif %}

Type guard

fn is_databricks(adapter: &AdapterImpl) -> bool { adapter.adapter_type() == AdapterType::Databricks }

Try / catch

// Catch-all unimplemented! arm panics for any non-Databricks type; check first
if adapter.adapter_type() == AdapterType::Databricks {
    let file_format = adapter.resolve_file_format(config)?;
}

Prevention

When it happens

Trigger: Calling adapter.resolve_file_format(config) from clone/table materialization logic while the adapter is not Databricks (Snowflake, BigQuery, DuckDB, Spark, Postgres, etc.). The catch-all arm at adapter_impl.rs:4530 fires for any non-Databricks adapter_type().

Common situations: Clone materialization macros from dbt-databricks run on another warehouse; a macro resolves file_format generically without an adapter guard; multi-platform projects where Databricks-only helpers execute for all targets.

Related errors


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