vectordotdev/vector · info

a record with a next ID must have an event count

Error message

a record with a next ID must have an event count

What it means

While deciding where to truncate a data file whose records cross the writer checkpoint, recovery reads `record.next_id` and then expect()s the paired `events` field. Records are constructed so both are set together (the scanner returns early for undecodable/empty records and only sets next_id as id + events), so a panic here means the record-construction invariant was broken internally. No on-disk input constructs a record with next_id but no event count.

Source

Thrown at lib/vector-buffers/src/variants/disk_v2/checkpoint_recovery.rs:704

    /// Returns the truncation boundary before a record that straddles the writer checkpoint.
    fn checkpoint_crossing_truncation_offset(
        scan: &CheckpointBoundaryScan<'_>,
        record: &CheckpointRecord,
    ) -> Option<u64> {
        let writer_next_record_id = scan.writer_next_record_id?;
        let next_id = record.next_id?;
        if next_id <= writer_next_record_id {
            return None;
        }

        let truncate_at = scan.current_offset();
        warn!(
            data_file_id = scan.file.id,
            writer_next_record_id,
            record_id = record.id,
            record_events = record
                .events
                .expect("a record with a next ID must have an event count"),
            truncate_at,
            "Record crosses writer checkpoint; truncating file."
        );
        Some(truncate_at)
    }

    /// Returns the physical file size, or `None` when the checkpointed file is missing.
    async fn data_file_size(&self, data_file_path: &Path) -> Result<Option<u64>, ReaderError<T>> {
        match self
            .ledger()
            .filesystem()
            .open_file_readable(data_file_path)
            .await
        {
            Ok(data_file) => data_file
                .metadata()
                .await
                .map(|metadata| Some(metadata.len()))

View on GitHub (pinned to 3708c39b12)

Solutions

1. Move the buffer data directory aside and restart to recreate it
2. If reproducible, capture RUST_BACKTRACE=1 output and file an upstream issue with the Vector version

When it happens

Trigger: A CheckpointRecord built with next_id set and events None, hit when a scanned record extends past writer_next_record_id during checkpoint recovery — reachable only through an internal Vector bug or memory corruption.

Common situations: Practically unseen; would appear in a crash report during disk_v2 buffer recovery after an unclean shutdown, on a state the scanner mis-built.

Related errors

• record was already validated
• Event count for a record cannot exceed 2^64 events.
• effective reader file ID must be in the checkpoint window
• event count should never exceed u64
• Ledger length cannot be greater than `u64`.

AI-assisted analysis of vectordotdev/vector@3708c39b12 (2026-08-20). Data as JSON: /api/errors/1e1bfd58afe393d7. Report an issue: GitHub.