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

Error message

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

What it means

'RangePartitioning.Range.Interval' is parsed as i64 with .expect while rebuilding the range partition config; a non-integer interval panics. BigQuery defines the range interval as a positive integer, so a parse failure means the metadata was produced incorrectly somewhere between the API and this code.

Source

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

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

    let partition_by = time_partition.or(range_partition);

    Ok(new_component(partition_by))
}

fn from_local_config(
    relation_config: &dyn InternalDbtNodeAttributes,

View on GitHub (pinned to 0267ce9170)

Solutions

Inspect and correct the metadata producer to emit the interval as a plain integer string.
Re-fetch table metadata from BigQuery to refresh stale values.
If decimals are possible upstream, parse via f64 and validate integrality before constructing Range.
Replace .expect with an AdapterError-returning path to avoid panics in production.

Example fix

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

Defensive patterns

Strategy: validation

Validate before calling

fn valid_range_interval(meta: &HashMap<String, String>) -> bool {
    meta.get("RangePartitioning.Range.Interval")
        .map(|s| s.trim().parse::<i64>().map(|v| v > 0).unwrap_or(false))
        .unwrap_or(true)
}

Prevention

Ensure the interval is serialized as a positive integer string
Pre-validate interval alongside Start/End before building RangeConfig
Refresh cached metadata after upgrades to avoid older serialization formats
Replace expects with error propagation in any forked code

When it happens

Trigger: from_remote_state encounters 'RangePartitioning.Range.Interval' that fails i64 parsing (empty string, decimal such as '1.0', formatted number, or placeholder).

Common situations: Serialization skew between driver versions (float-encoded interval); cached/hand-edited metadata; another tool writing the schema metadata with different types.

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