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
- Guard with adapter.type() == 'databricks' and use a platform-appropriate default (or the model's own file_format config) elsewhere
- Keep resolve_file_format calls inside Databricks-only materialization branches
- 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
- Never call resolve_file_format from platform-neutral materializations
- Use the model's own file_format config with a per-platform default elsewhere
- Pin clone materializations to Databricks targets in project selectors
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
- only available with Databricksadapter
- only available with Databricks adapter
- update_tblproperties_for_uniform_iceberg is only supported i
- is_uniform is only supported in Databricks
- supports_create_or_replace is not implemented for {:?}
AI-assisted analysis of dbt-labs/dbt-core@0267ce9170 (2026-09-07).
Data as JSON: /api/errors/8a0522afc89208da.
Report an issue: GitHub.