What causes "Could not parse 'RangePartitioning.Range.End' as i64" in dbt-labs/dbt-core?

Inspect the raw metadata string and fix the producer to emit plain integer text.

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

Error message

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

What it means

Same family as the Range.Start case: 'RangePartitioning.Range.End' from the remote schema metadata is parsed as i64 with .expect; a non-integer value panics. BigQuery always reports the range end as an integer, so a parse failure indicates corrupted or foreign metadata.

Source

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

        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(),
                },
            }),
            // TODO(serramatutu): how do we determine the value of this?
            copy_partitions: false,
        })
    } else {
        None
    };

View on GitHub (pinned to 0267ce9170)

Solutions

Inspect the raw metadata string and fix the producer to emit plain integer text.
Re-fetch schema metadata from the live BigQuery API to overwrite corrupted cache.
Use a tolerant parse (trim, strip separators) if upstream formatting cannot be changed immediately.
Convert the .expect into a mapped AdapterError for a diagnosable failure.

Example fix

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

Defensive patterns

Strategy: validation

Validate before calling

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

Prevention

Pre-validate all three range metadata values (Start/End/Interval) together before reconciliation
Serialize bounds as plain integers, never floats or formatted strings
Re-fetch metadata from BigQuery after tooling/driver version changes
Convert expects to errors upstream so bad values surface with context

When it happens

Trigger: from_remote_state sees 'RangePartitioning.Range.End' whose value fails i64 parsing (empty, decimal, comma-formatted, or placeholder text).

Common situations: Upstream tooling serializing the bound as a float string; stale or hand-edited cached schema metadata; driver/adapter version skew changing how the bound is serialized.

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/d02966a587584112. Report an issue: GitHub.