Could not parse 'RangePartitioning.Range.Start' as i64

Error message

Could not parse 'RangePartitioning.Range.Start' as i64

What it means

When rebuilding a BigQuery range-partition config from remote schema metadata, the 'RangePartitioning.Range.Start' string is parsed as i64 with .expect, so any non-integer value panics with this message. It is treated as corruption of the driver-provided metadata, since BigQuery's API should always report range bounds as integers.

Source

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

            copy_partitions: false,
        })
    } else {
        None
    };

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

        Some(BigqueryPartitionConfig {
            field,
            data_type: "int64".to_string(),
            __inner__: BigqueryPartitionConfigInner::Range(RangeConfig {
                range: Range {
                    start: metadata
                        .get("RangePartitioning.Range.Start")
                        .map(|s| {
                            s.parse::<i64>()
                                .expect("Could not parse 'RangePartitioning.Range.Start' as i64")
                        })
                        .unwrap(),
                    end: metadata
                        .get("RangePartitioning.Range.End")
                        .map(|s| {
                            s.parse::<i64>()
                                .expect("Could not parse 'RangePartitioning.Range.End' as i64")
                        })
                        .unwrap(),
                    interval: metadata
                        .get("RangePartitioning.Range.Interval")
                        .map(|s| {
                            s.parse::<i64>()
                                .expect("Could not parse 'RangePartitioning.Range.Interval' as i64")
                        })
                        .unwrap(),
                },
            }),

View on GitHub (pinned to 0267ce9170)

Solutions

Print the raw metadata value and fix whatever writes it to emit a plain base-10 integer string.
Re-fetch the table metadata from BigQuery to replace stale/corrupted cached values.
If bounds may exceed i64 or be formatted, parse with a tolerant parser (f64 then validate, or i128) before constructing Range.
Replace .expect with a proper error so a bad value yields a diagnosable AdapterError instead of a panic.

Example fix

// before
s.parse::<i64>()
    .expect("Could not parse 'RangePartitioning.Range.Start' as i64")
// after
s.parse::<i64>().map_err(|e| AdapterError::new(
    AdapterErrorKind::Internal,
    format!("invalid RangePartitioning.Range.Start '{s}': {e}")))?

Defensive patterns

Strategy: validation

Validate before calling

fn valid_range_start(meta: &HashMap<String, String>) -> bool {
    meta.get("RangePartitioning.Range.Start")
        .map(|s| s.trim().parse::<i64>().is_ok())
        .unwrap_or(true)
}

Prevention

Validate range metadata values parse as i64 before invoking remote-state reconciliation
Emit range bounds as plain base-10 integer strings in any custom driver/middleware
Avoid formatting (thousand separators, decimals) when serializing BigQuery range values
Refresh cached schemas from the API after adapter upgrades

When it happens

Trigger: from_remote_state encounters metadata 'RangePartitioning.Range.Start' whose value fails i64 parsing (empty string, floats, quoted/formatted numbers like '1,000', or a placeholder set by another tool).

Common situations: A driver or middleware serializing range bounds as floats/strings with formatting; hand-edited or cached schema metadata; localized number formatting injected upstream; metadata produced by an older adapter version with different encoding.

Understand the failure class

Background: "Invalid ... format", "must be in format X", "does not look like a ..." — invalid argument format errors across CLI tools and libraries — this error's family across 17 libraries.

Related errors

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