nautechsystems/nautilus_trader · error · anyhow::Error

Warning: Column name '{column_name}' is not of type i64.

Error message

Warning: Column name '{column_name}' is not of type i64.

What it means

min_max_from_parquet_metadata_object_store extracts min/max timestamp bounds from Parquet row-group statistics and requires the timestamp column to be physical type int64. If the statistics for the requested column are not Int64, it bails. (Note: it is a hard bail despite the 'Warning:' prefix.)

Source

Thrown at crates/persistence/src/parquet.rs:450

            if col_metadata.column_path().string() == column_name {
                if let Some(stats) = col_metadata.statistics() {
                    // Check if we have Int64 statistics
                    if let Statistics::Int64(int64_stats) = stats {
                        // Extract min value if available
                        if let Some(&min_value) = int64_stats.min_opt()
                            && overall_min_value.is_none_or(|overall_min| min_value < overall_min)
                        {
                            overall_min_value = Some(min_value);
                        }

                        // Extract max value if available
                        if let Some(&max_value) = int64_stats.max_opt()
                            && overall_max_value.is_none_or(|overall_max| max_value > overall_max)
                        {
                            overall_max_value = Some(max_value);
                        }
                    } else {
                        anyhow::bail!("Warning: Column name '{column_name}' is not of type i64.");
                    }
                } else {
                    anyhow::bail!(
                        "Warning: Statistics not available for column '{column_name}' in row group {i}."
                    );
                }
            }
        }
    }

    // Return the min/max pair if both are available
    if let (Some(min), Some(max)) = (overall_min_value, overall_max_value) {
        Ok((
            u64::try_from(min).map_err(|_| {
                anyhow::anyhow!("Negative minimum value {min} for column '{column_name}'")
            })?,
            u64::try_from(max).map_err(|_| {
                anyhow::anyhow!("Negative maximum value {max} for column '{column_name}'")

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Rewrite the file with nautilus' Parquet writer so timestamps are stored as int64 nanos.
  2. Confirm the timestamp_column argument names the int64 timestamp column, not another column.
  3. Convert external Parquet files: cast the timestamp column to int64 before placing them in the catalog.
  4. Align writer/reader versions so column types match what this build expects.

Example fix

// before — external file with timestamp[us] column
catalog.reset_file_names(&directory, "timestamp")?;
// after — cast to int64 nanos first
let df = df.with_column(col("timestamp").cast(DataType::Int64))?;
Defensive patterns

Strategy: validation

Validate before calling

// verify physical type before calling
let schema = file_metadata.schema();
let col = schema.column_with_name(timestamp_column)
    .ok_or("missing timestamp column")?;
debug_assert_eq!(col.1.physical_type(), parquet::basic::Type::INT64);

Try / catch

match min_max_from_parquet_metadata(meta, timestamp_column) {
    Err(e) if e.to_string().contains("not of type i64") => {
        // fall back to rewriting the file with int64 timestamps
    }
    other => other?,
}

Prevention

When it happens

Trigger: Calling reset_file_names or min_max_from_parquet_metadata on a Parquet file whose timestamp column was written as a non-i64 physical type (e.g. timestamp micros/millis logical type, int96, or a different column passed as timestamp_column).

Common situations: Files written by external tools (pandas/pyarrow with timestamp dtype) instead of nautilus' writer; passing a non-timestamp column name; catalogs written by a different writer version with different column encoding.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/a9eaa7baf9a69587. Report an issue: GitHub.