dbt-labs/dbt-core · error

get_bq_table

Error message

get_bq_table

What it means

get_bq_table is a stub that panics unconditionally. It corresponds to the BigQuery adapter's get_table hook (upstream impl.py L1187) which fetches a Google BigQuery Table resource for a relation; the Rust port has not implemented it for any adapter.

Source

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

        data_type: &str,
    ) -> Result<Value, minijinja::Error> {
        match self.adapter_type() {
            Bigquery => Ok(Value::from(render_struct_projection(col_name, data_type))),
            Postgres | Snowflake | Databricks | Redshift | Salesforce | Spark | DuckDB
            | LakeCompute | Fabric | ClickHouse | Exasol | Starburst | Athena | Trino
            | Datafusion | Dremio | Oracle => {
                unimplemented!("only available with BigQuery adapter")
            }
        }
    }

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

    /// BigQueryAdapter https://github.com/dbt-labs/dbt-adapters/blob/0efd8d3d1081e1ab43e38797d5104f7b424a6284/dbt-bigquery/src/dbt/adapters/bigquery/impl.py#L1219
    #[allow(clippy::too_many_arguments)]
    pub fn grant_access_to(
        &self,
        state: &State,
        conn: &'_ mut dyn Connection,
        entity: &Arc<dyn BaseRelation>,
        entity_type: &str,
        // _role is not used since this method only supports view
        // and googleapi doesn't require role if the entity is view, it'll be default to READ always
        _role: Option<&str>,
        database: &str,
        schema: &str,
        token: CancellationToken,
    ) -> AdapterResult<Value> {
        match self.adapter_type() {

View on GitHub (pinned to 0267ce9170)

Solutions

  1. Avoid macros that call get_bq_table until the hook is implemented.
  2. Fetch table metadata through information_schema queries instead where possible.
  3. Implement get_bq_table using the BigQuery client's tables.get in adapter_impl.rs (~line 3234).

Example fix

// before
pub fn get_bq_table(&self, _state: &State, _relation: &Arc<dyn BaseRelation>) -> Result<Value, minijinja::Error> {
    unimplemented!("get_bq_table")
}
// after
pub fn get_bq_table(&self, _state: &State, _relation: &Arc<dyn BaseRelation>) -> Result<Value, minijinja::Error> {
    Err(minijinja::Error::new(
        minijinja::ErrorKind::InvalidOperation,
        "get_bq_table is not yet implemented",
    ))
}
Defensive patterns

Strategy: try-catch

Type guard

fn has_bq_table_hook(adapter: &AdapterImpl) -> bool { false /* stub until implemented */ }

Try / catch

let table = match std::panic::catch_unwind(|| adapter.get_bq_table(&state, &relation)) {
    Ok(t) => t?,
    Err(_) => fetch_table_metadata_via_information_schema(&relation)?,
};

Prevention

When it happens

Trigger: Invoking AdapterImpl::get_bq_table(state, relation) from Jinja/macros that need BigQuery table metadata (partitioning, clustering, expiration, labels).

Common situations: Macros or materializations relying on the BigQuery get_table API; porting BigQuery-specific dbt packages to the Rust engine.

Related errors


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