BigQuery returned invalid 'TimePartitioning.Field'. This is

Error message

BigQuery returned invalid 'TimePartitioning.Field'. This is a driver bug.

What it means

After resolving the partition field's type, from_remote_state looks up the field named by 'TimePartitioning.Field' in the schema's fields; if no such field exists (or the lookup errors), this second .expect panics, declaring that BigQuery returned a TimePartitioning.Field that doesn't correspond to any field in the returned schema — a driver/API inconsistency treated as a bug.

Source

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

}

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
    };

    let range_partition = if let Some(partition) = metadata.get("RangePartitioning.Field") {
        let field = partition.parse::<String>().unwrap();

View on GitHub (pinned to 0267ce9170)

Solutions

Re-fetch the table schema so metadata and fields come from the same consistent snapshot.
Check for exact-case mismatch between the 'TimePartitioning.Field' value and the field names; normalize case before lookup.
Handle pseudo-columns (e.g. _PARTITIONTIME/_PARTITIONDATE ingestion partitioning) explicitly instead of expecting them in schema.fields().
Report to maintainers if the live BigQuery API genuinely returns a partitioning field absent from the schema.

Example fix

// before
.expect("BigQuery returned invalid 'TimePartitioning.Field'. This is a driver bug.");
// after
.ok_or_else(|| AdapterError::new(AdapterErrorKind::Internal,
    format!("TimePartitioning.Field '{field_name}' not found in schema")))?

Defensive patterns

Strategy: validation

Validate before calling

fn partition_field_exists(schema: &arrow_schema::Schema) -> bool {
    schema.metadata.get("TimePartitioning.Field")
        .map(|f| schema.fields().find(f).is_some())
        .unwrap_or(true) // no time partitioning declared
}

Prevention

Re-fetch table schema rather than reusing cached metadata after DDL changes
Normalize field-name case (BigQuery is case-insensitive) before exact lookups
Handle pseudo partitioning columns (_PARTITIONTIME/_PARTITIONDATE) separately from schema fields
Ensure the driver returns metadata and fields from the same API snapshot

When it happens

Trigger: Calling from_remote_state (via from_remote_state_no_labels / from_remote_state_with_labels) on a schema whose metadata declares 'TimePartitioning.Field' = X, but whose field list contains no field named X (case mismatch, dropped column, or stale metadata).

Common situations: Schema fetched from a stale cache while the table was altered; driver returning metadata and fields from different API calls; pseudo/column-case differences (BigQuery is case-insensitive, the Arrow lookup is exact); partitioning on a pseudo-column like _PARTITIONTIME not present in fields.

Understand the failure class

Background: 'Could not be found', 'does not exist', 'not found in database': the resource-not-found family when an ID, slug, key, or URI lookup comes back empty — this error's family across 20 libraries.

Related errors

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