No 'BIGQUERY:type' in field metadata. This is a driver bug.

Error message

No 'BIGQUERY:type' in field metadata. This is a driver bug.

What it means

When reconstructing BigQuery partition config from a remote table's Arrow schema metadata, the code finds the TimePartitioning.Field and calls original_type_string(Bigquery, field), which requires each field to carry a 'BIGQUERY:type' metadata entry. If the field lacks that metadata, the mapping returns None and this .expect panics, asserting that the driver that produced the schema forgot to attach BigQuery type metadata — a driver bug, not user error.

Source

Thrown at crates/dbt-adapter/src/relation/bigquery/config/components/partition_by.rs:47

        to_jinja_fn: to_jinja,
        value: cfg,
    }
}

fn from_remote_state(schema: &Schema) -> AdapterResult<PartitionBy> {
    let metadata = &schema.metadata;
    let time_partition = if let Some(partition) = metadata.get("TimePartitioning.Field") {
        let field_name = partition.parse::<String>().unwrap();

        let data_type = schema
            .fields()
            .find(&field_name)
            .map(|(_, field)| {
                dbt_adapter_sql::types::original_type_string(
                    dbt_adapter_core::AdapterType::Bigquery,
                    field,
                )
                .expect("No 'BIGQUERY:type' in field metadata. This is a driver bug.")
                .to_string()
            })
            .expect("BigQuery returned invalid 'TimePartitioning.Field'. This is a driver bug.");

        Some(BigqueryPartitionConfig {
            field: field_name,
            data_type,
            __inner__: BigqueryPartitionConfigInner::Time(TimeConfig {
                granularity: metadata.get("TimePartitioning.Type").unwrap().to_string(),
                time_ingestion_partitioning: false,
            }),
            // TODO(serramatutu): how do we determine the value of this?
            copy_partitions: false,
        })
    } else {
        None
    };

View on GitHub (pinned to 0267ce9170)

Solutions

Confirm the schema came from the BigQuery driver and that it attaches 'BIGQUERY:type' to every field; re-fetch the schema from the live API.
Inspect field.metadata() for the partitioning field and check which key it actually carries (e.g. a renamed metadata key after a driver update) — align the key with what the driver emits.
Pin/upgrade dbt BigQuery driver/adapter components to matching versions so metadata emission and consumption agree.
If you construct schemas in tests/tools, add metadata "BIGQUERY:type" to the partitioning field before calling from_remote_state.

Example fix

// before
.expect("No 'BIGQUERY:type' in field metadata. This is a driver bug.")
// after
.ok_or_else(|| AdapterError::new(AdapterErrorKind::Internal,
    format!("field '{field_name}' missing BIGQUERY:type metadata")))?

Defensive patterns

Strategy: validation

Validate before calling

fn has_bq_type(schema: &arrow_schema::Schema, field_name: &str) -> bool {
    schema.fields().find(field_name)
        .map(|(_, f)| f.metadata().contains_key("BIGQUERY:type"))
        .unwrap_or(false)
}
// check before from_remote_state / relation reconciliation

Prevention

Always obtain schemas through the BigQuery driver, which attaches 'BIGQUERY:type' metadata
Don't mix schemas from other adapters into BigQuery relation reconciliation
After driver upgrades, diff emitted field metadata keys against what the adapter expects
In tests, build schemas with the required BIGQUERY:type metadata on every field

When it happens

Trigger: Calling from_remote_state (directly or via from_remote_state_no_labels / from_remote_state_with_labels) on a schema where a field named by 'TimePartitioning.Field' exists but has no 'BIGQUERY:type' entry in its field metadata — typically when a non-BigQuery driver or a hand-built Arrow schema is passed through the BigQuery remote-state path.

Common situations: Using a mocked or cached schema built without driver metadata; a driver upgrade that stopped emitting 'BIGQUERY:type'; passing a view/materialized-view schema from a different adapter backend into BigQuery relation reconciliation.

Understand the failure class

Background: "is required", "must be set", "missing required field": configuration validation errors across open-source libraries — this error's family across 36 libraries.

Related errors

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