What causes "record was already validated" in vectordotdev/vector?

Move the buffer data directory aside and restart so the buffer is recreated (drops buffered events)

record was already validated

Error message

record was already validated

What it means

While classifying the final data file during disk_v2 checkpoint recovery, Vector first validates the record archive (checksum) and only re-parses it with `try_as_record_archive` after validation returned `RecordStatus::Valid`. The second parse is expected to succeed because validation already succeeded; if the two parsers disagree, this invariant panic aborts recovery. There is no configuration that legitimately produces the disagreement.

Source

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

            Ok(data_file_mmap) => data_file_mmap,
            Err(e) if e.kind() == ErrorKind::NotFound => {
                error!(
                    data_file_id,
                    "Missing checkpointed data file before unread boundary; treating records as lost."
                );
                return Ok(DataFileClassification::Missing);
            }
            Err(e) => return Err(ReaderError::Io { source: e }),
        };

        if data_file_mmap.as_ref().is_empty() {
            return Ok(DataFileClassification::Empty);
        }

        match validate_record_archive(data_file_mmap.as_ref(), &Hasher::new()) {
            RecordStatus::Valid { id: last_record_id } => {
                let record = try_as_record_archive(data_file_mmap.as_ref())
                    .expect("record was already validated");
                let item = match decode_record_payload::<T>(record) {
                    Ok(item) => item,
                    Err(error) => {
                        warn!(
                            data_file_id,
                            %error,
                            "Final checkpoint record could not be decoded; scanning file boundary."
                        );
                        return Ok(DataFileClassification::NeedsBoundaryScan);
                    }
                };
                let record_events =
                    u64::try_from(item.event_count()).expect("event count should never exceed u64");
                Ok(DataFileClassification::KnownLastRecord {
                    last_record_id: last_record_id + record_events.saturating_sub(1),
                })
            }
            RecordStatus::Corrupted { .. } => {

View on GitHub (pinned to 3708c39b12)

Solutions

Move the buffer data directory aside and restart so the buffer is recreated (drops buffered events)
Re-run with RUST_BACKTRACE=1 and preserve the original data files for the report
File an upstream issue with the Vector version, backtrace, and (if shareable) the offending data file

Defensive patterns

Strategy: fallback

Prevention

Preserve buffer data directories across restarts on stable storage; avoid hard kills during heavy buffered writes
Keep a runbook step to move the data directory aside and restart when recovery panics loop
Save the moved-aside files until an upstream triage confirms whether they are needed

When it happens

Trigger: Recovery encountering a data file that passes `validate_record_archive` but then fails `try_as_record_archive` — realistically only via memory/hardware corruption or a genuine parser-disagreement bug in Vector; triggered at sink buffer construction when the final data file is scanned.

Common situations: Extremely rare; appears after unclean shutdowns or on flaky hardware where recovery lands on a torn state; otherwise it indicates an internal Vector bug worth reporting with the data file.

Related errors

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