dbt-labs/dbt-core · error · minijinja::Error

describe_interactive_table is not supported by the {} adapte

Error message

describe_interactive_table is not supported by the {} adapter

What it means

describe_interactive_table mirrors describe_dynamic_table: it is implemented only for certain adapter types, and the same exclusion list raises an InvalidOperation error naming the adapter. Interactive tables are a warehouse-specific feature, so unsupported adapters refuse the operation.

Source

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

                        &INTERACTIVE_TABLE_COLUMNS
                            .iter()
                            .map(|s| s.to_string())
                            .collect::<Vec<_>>(),
                    );

                Ok(Value::from(ValueMap::from([(
                    Value::from(INTERACTIVE_TABLE_KEY),
                    Value::from_object(table),
                )])))
            }
            Postgres | Bigquery | Databricks | Redshift | Salesforce | Spark | DuckDB
            | LakeCompute | Fabric | ClickHouse | Exasol | Starburst | Athena | Trino
            | Datafusion | Dremio | Oracle => {
                let err = format!(
                    "describe_interactive_table is not supported by the {} adapter",
                    adapter_type
                );
                Err(minijinja::Error::new(
                    minijinja::ErrorKind::InvalidOperation,
                    err,
                ))
            }
        }
    }

    /// SQLAdapter https://github.com/dbt-labs/dbt-adapters/blob/0efd8d3d1081e1ab43e38797d5104f7b424a6284/dbt-adapters/src/dbt/adapters/sql/impl.py#L145
    pub fn drop_relation(
        &self,
        state: &State,
        relation: &Arc<dyn BaseRelation>,
    ) -> AdapterResult<Value> {
        if self.mock_state().is_some() {
            return Ok(none_value());
        }
        match self.inner_adapter() {
            Replay(_, replay) => replay.replay_drop_relation(state, relation),

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Only call describe_interactive_table on adapters that implement it.
  2. Add an adapter-type check or try/catch fallback in the calling macro.
  3. Implement the method for the target adapter if the feature is required there.

Example fix

-- before
{% set info = describe_interactive_table(relation) %}

// after
{% if adapter_type() in ['snowflake'] %}
  {% set info = describe_interactive_table(relation) %}
{% endif %}
Defensive patterns

Strategy: fallback

Validate before calling

{% set SUPPORTED = ['snowflake'] %}
{% set ok = adapter_type() in SUPPORTED %}

Type guard

fn supports_interactive_tables(adapter_type: &str) -> bool {
    matches!(adapter_type, "snowflake")
}

Try / catch

{% try %}
  {% set info = describe_interactive_table(relation) %}
{% except %}
  {% set info = none %}
{% endtry %}

Prevention

When it happens

Trigger: Calling describe_relation → describe_interactive_table on a relation typed as interactive table while using LakeCompute, Fabric, ClickHouse, Exasol, Starburst, Athena, Trino, Datafusion, Dremio, Oracle, or another unsupported adapter.

Common situations: Same as dynamic tables: cross-warehouse model reuse, generic audit macros, or porting Snowflake-specific features to other platforms.

Understand the failure class

Background: UnsupportedOperationException and "is not supported" errors: when a library deliberately refuses a call — this error's family across 30 libraries.

Related errors


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