vectordotdev/vector · info

the slice is the length of a u64

Error message

the slice is the length of a u64

What it means

The v2 disk buffer reader frames each record with an 8-byte big-endian length. When at least 8 bytes are buffered, the code slices exactly `buffer()[..8]` and converts that slice into `[u8; 8]` for `u64::from_be_bytes`. Because the slice is constructed with a fixed length of 8 after the `available >= 8` check, the try_into is infallible; the expect only guards against future refactors breaking that shape.

Source

Thrown at lib/vector-buffers/src/variants/disk_v2/reader.rs:258

            aligned_buf: AlignedVec::new(),
            checksummer: create_crc32c_hasher(),
            current_record_id: 0,
            _t: PhantomData,
        }
    }

    #[cfg_attr(test, instrument(skip(self), level = "trace"))]
    async fn read_length_delimiter(
        &mut self,
        is_finalized: bool,
    ) -> Result<Option<usize>, ReaderError<T>> {
        loop {
            let available = self.reader.buffer().len();
            if available >= 8 {
                let length_buf = &self.reader.buffer()[..8];
                let length = length_buf
                    .try_into()
                    .expect("the slice is the length of a u64");
                self.reader.consume(8);

                // By default, records cannot exceed 8MB in length, so whether our `usize` is a u32
                // or u64, we're not going to overflow it.  While the maximum record size _can_ be
                // changed, it's not currently exposed to users.  Even further, if it was exposed to
                // users, it's currently a `usize`, so again, we know that we're not going to exceed
                // 64-bit. And even further still, the writer fallibly attempts to get a `u64` of the
                // record size based on the encoding buffer, which gives its length in `usize`, and
                // so would fail if `usize` was larger than `u64`, meaning we at least will panic if
                // Vector is running on a 128-bit CPU in the future, storing records that are larger
                // than 2^64+1. :)
                let record_len = u64::from_be_bytes(length)
                    .try_into()
                    .expect("record length should never exceed usize");
                return Ok(Some(record_len));
            }

            // We don't have enough bytes, so we need to fill our buffer again.

View on GitHub (pinned to 3708c39b12)

Solutions

1. No action possible; report upstream with the backtrace if it ever fires

When it happens

Trigger: A byte slice whose length is not exactly 8 reaching the conversion — precluded by the `available >= 8` check and the `[..8]` slice; only a code regression inside read_length_delimiter could trip it.

Common situations: None; the invariant is enforced two lines above the expect.

Related errors

• record was already validated
• event count should never exceed u64
• Event count for a record cannot exceed 2^64 events.
• a record with a next ID must have an event count
• Ledger length cannot be greater than `u64`.

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