What causes "get_partitions_metadata" in dbt-labs/dbt-core?

Remove or guard calls to get_partitions_metadata in custom macros until the hook is implemented.

get_partitions_metadata

Error message

get_partitions_metadata

What it means

get_partitions_metadata is a stub that unconditionally panics with unimplemented!. In upstream dbt-adapters (BaseAdapter impl.py), this API returns partition metadata for a relation, but the Rust port has not implemented it for any adapter. Any call immediately aborts the thread.

Solutions

Remove or guard calls to get_partitions_metadata in custom macros until the hook is implemented.
Implement the method in adapter_impl.rs (line ~702) returning partition metadata via the adapter's information_schema queries.
Wrap the call site in catch_unwind or an adapter-level capability check so projects degrade gracefully.

Example fix

// before
pub fn get_partitions_metadata(&self, _state: &State, _relation: &dyn BaseRelation) -> Result<Value, minijinja::Error> {
    unimplemented!("get_partitions_metadata")
}
// after
pub fn get_partitions_metadata(&self, _state: &State, _relation: &dyn BaseRelation) -> Result<Value, minijinja::Error> {
    Err(minijinja::Error::new(
        minijinja::ErrorKind::InvalidOperation,
        "get_partitions_metadata is not supported by this adapter",
    ))
}

Defensive patterns

Strategy: try-catch

Type guard

fn has_partitions_metadata_hook(adapter_type: &str) -> bool { /* false until the hook is implemented */ false }

Try / catch

match std::panic::catch_unwind(|| adapter.get_partitions_metadata(&state, relation)) {
    Ok(v) => v,
    Err(_) => default_partition_metadata(),
}

Prevention

Avoid custom macros that call get_partitions_metadata in the Rust engine
Feature-detect adapter hooks before invoking them
Track the upstream port status of BaseAdapter hooks before relying on them

When it happens

Trigger: Invoking AdapterImpl::get_partitions_metadata(&state, &relation) from Jinja templates or adapter-dispatched code, e.g. when a model or macro queries partition metadata of a table.

Common situations: Porting macros that rely on the Python BaseAdapter get_partitions_metadata hook; running dbt projects whose macros inspect table partitions.

Related errors

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

Appendix: source

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

            .map(|pair| {
                let key = pair.split('=').next().unwrap_or("").trim();
                format!("{key} = '[REDACTED]'")
            })
            .collect::<Vec<_>>()
            .join(", ");

        let redacted_sql = sql.replacen(full_parens, &format!("({redacted_pairs})"), 1);

        Ok(redacted_sql)
    }

    /// BaseAdapter https://github.com/dbt-labs/dbt-adapters/blob/0efd8d3d1081e1ab43e38797d5104f7b424a6284/dbt-adapters/src/dbt/adapters/base/impl.py#L505
    pub fn get_partitions_metadata(
        &self,
        _state: &State,
        _relation: &dyn BaseRelation,
    ) -> Result<Value, minijinja::Error> {
        unimplemented!("get_partitions_metadata")
    }

    /// Borrow the current thread-local connection or create one if it's not set yet.
    ///
    /// A guard is returned. When destroyed, the guard returns the connection to
    /// the thread-local variable. If another connection became the thread-local
    /// in the mean time, that connection is dropped and the return proceeds as
    /// normal.
    pub fn borrow_tlocal_connection(
        &self,
        state: Option<&State>,
        node_id: Option<String>,
    ) -> Result<ConnectionGuard<'_>, AdapterError> {
        borrow_tlocal_connection(self.engine().as_ref(), state, node_id)
    }

    /// Helper method for execute
    #[allow(clippy::too_many_arguments)]

View on GitHub (pinned to 0267ce9170)