vectordotdev/vector · info

Ledger length cannot be greater than `u64`.

Error message

Ledger length cannot be greater than `u64`.

What it means

When computing the maximum possible data-file size for a disk_v2 buffer, Vector converts the compile-time constant LEDGER_LEN (the aligned size of the archived ledger state, defined in ledger.rs) from `usize` to `u64`. Because it is a fixed build-time constant that fits in u64 by construction, this expect can never fail on any real target; it exists purely to document the type-level invariant.

Source

Thrown at lib/vector-buffers/src/variants/disk_v2/common.rs:100

///
/// This is required due to the overalignment used in record serialization, such that we can correctly determine minimum
/// on-disk sizes for various elements, and account for those in size limits, etc.
pub(crate) const fn align16(amount: usize) -> usize {
    // The amount must be less than `MAX_ALIGNABLE_AMOUNT` otherwise we'll overflow trying to align it, ending up with a
    // nonsensical value.
    assert!(
        amount <= MAX_ALIGNABLE_AMOUNT,
        "`amount` must be less than `MAX_ALIGNABLE_AMOUNT`"
    );

    amount.div_ceil(SERIALIZER_ALIGNMENT) * SERIALIZER_ALIGNMENT
}

/// Gets the maximum possible data file size given the type-level numerical limits and buffer invariants.
fn get_maximum_data_file_size() -> u64 {
    let ledger_len: u64 = LEDGER_LEN
        .try_into()
        .expect("Ledger length cannot be greater than `u64`.");
    (u64::MAX - ledger_len) / 2
}

/// Gets the minimum buffer size for the given maximum data file size.
///
/// This ensures that we are allowed to store enough bytes on-disk, as the buffer design requires being able to always
/// write to a minimum number of data files, etc. This allow ensures that we're accounting for non-data file disk usage
/// so that we do not overrun the specified maximum buffer size when considering the sum total of files placed on disk.
fn get_minimum_buffer_size(max_data_file_size: u64) -> Option<u64> {
    // We're doing this fallible conversion back-and-forth because we have to interoperate with `u64` and `usize`, and
    // we need to ensure we're not getting values that can't be represented correctly in both types, as well as ensuring
    // we're not implicitly overflowing and generating nonsensical numbers.
    let ledger_len = LEDGER_LEN
        .try_into()
        .expect("Ledger length cannot be greater than `u64`.");

    // We always need to be able to allocate two data files, so the buffer size has to be at least as big as 2x data
    // files at their maximum allowed size, plus an allowance for the size of the ledger state itself.

View on GitHub (pinned to 3708c39b12)

Solutions

  1. No action possible or needed; if it ever appears, report it as an upstream bug
Defensive patterns

Strategy: validation

Prevention

When it happens

Trigger: Compiling or running on a hypothetical platform where `usize` is wider than u64 AND the ledger state exceeds 2^64 bytes — no such platform exists; nothing at runtime triggers it.

Common situations: None; the value is baked in at compile time and is a few hundred bytes at most.

Related errors


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