quickwit-oss/quickwit · error

Failed to create `OffsetDateTime` from split create timestam

Error message

Failed to create `OffsetDateTime` from split create timestamp.

What it means

make_split_table converts each split's create_timestamp (a Unix seconds value from the metastore) into a time::OffsetDateTime for display. OffsetDateTime::from_unix_timestamp fails only for timestamps outside the representable range (roughly year -9999..9999); the expect asserts metastore timestamps are always sane, so the panic indicates corrupted metadata.

Source

Thrown at quickwit/quickwit-cli/src/split.rs:403

    //     }
    //     let hotcache_table = make_table("Files in Hotcache", hotcache_files.into_iter(), false);
    //     println!("{hotcache_table}");
    // }
    Ok(())
}

fn make_split_table(splits: &[Split], title: &str) -> Table {
    let rows = splits
        .iter()
        .map(|split| {
            let time_range = if let Some(time_range) = &split.split_metadata.time_range {
                format!("[{time_range:?}]")
            } else {
                "[*]".to_string()
            };
            let created_at =
                OffsetDateTime::from_unix_timestamp(split.split_metadata.create_timestamp)
                    .expect("Failed to create `OffsetDateTime` from split create timestamp.");
            let updated_at = OffsetDateTime::from_unix_timestamp(split.update_timestamp)
                .expect("Failed to create `OffsetDateTime` from split update timestamp.");

            SplitRow {
                split_id: split.split_metadata.split_id.clone(),
                split_state: split.split_state,
                num_docs: split.split_metadata.num_docs,
                size_mega_bytes: split.split_metadata.uncompressed_docs_size_in_bytes / 1_000_000,
                created_at,
                updated_at,
                time_range,
            }
        })
        .sorted_by(|left, right| left.created_at.cmp(&right.created_at));
    make_table(title, rows, false)
}

fn parse_date(date_arg: &str, option_name: &str) -> anyhow::Result<OffsetDateTime> {

View on GitHub (pinned to a39730c5cd)

Solutions

  1. Inspect the offending split's metadata (e.g. via the metastore DB) and correct the create_timestamp.
  2. Delete/re-upload the corrupt split so metadata is regenerated.
  3. In display code, fall back to showing the raw timestamp or a placeholder instead of panicking.

Example fix

// before
OffsetDateTime::from_unix_timestamp(split.split_metadata.create_timestamp)
    .expect("Failed to create `OffsetDateTime` from split create timestamp.")
// after
OffsetDateTime::from_unix_timestamp(split.split_metadata.create_timestamp)
    .unwrap_or(OffsetDateTime::UNIX_EPOCH)
Defensive patterns

Strategy: fallback

Validate before calling

let ts = split.split_metadata.create_timestamp;
let valid = (0..=253_402_300_799).contains(&ts); // 10000-01-01 upper bound in seconds

Type guard

fn is_sane_unix_ts(ts: i64) -> bool { (0..=253_402_300_799).contains(&ts) }

Try / catch

OffsetDateTime::from_unix_timestamp(ts)
    .unwrap_or(OffsetDateTime::UNIX_EPOCH)

Prevention

When it happens

Trigger: Listing splits where a split's split_metadata.create_timestamp is negative, zero-corrupt, absurdly large, or otherwise out of OffsetDateTime's valid Unix-seconds range.

Common situations: Hand-edited or migrated metastore rows with bogus timestamps; corruption when importing splits from another index; clock misconfiguration at indexing time producing extreme values.

Related errors


AI-assisted analysis of quickwit-oss/quickwit@a39730c5cd (2026-09-08). Data as JSON: /api/errors/b54073b8027560db. Report an issue: GitHub.