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
- No action possible or needed; if it ever appears, report it as an upstream bug
Defensive patterns
Strategy: validation
Prevention
- Nothing to guard: the value is a compile-time constant that fits u64 on all supported targets
- Track Vector releases for any change to the ledger format if this ever fires
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
- event count should never exceed u64
- Event count for a record cannot exceed 2^64 events.
- Default maximum data file size should never be greater than
- Vector only supports record sizes that fit in u64
- record was already validated
AI-assisted analysis of vectordotdev/vector@3708c39b12 (2026-08-20).
Data as JSON: /api/errors/0b671f9627d2576a.
Report an issue: GitHub.