{"record":{"id":"0b671f9627d2576a","repo":"vectordotdev/vector","slug":"ledger-length-cannot-be-greater-than-u64","errorCode":null,"errorMessage":"Ledger length cannot be greater than `u64`.","messagePattern":"Ledger length cannot be greater than `u64`\\.","errorType":"panic","errorClass":null,"httpStatus":null,"severity":"info","filePath":"lib/vector-buffers/src/variants/disk_v2/common.rs","lineNumber":100,"sourceCode":"///\n/// This is required due to the overalignment used in record serialization, such that we can correctly determine minimum\n/// on-disk sizes for various elements, and account for those in size limits, etc.\npub(crate) const fn align16(amount: usize) -> usize {\n    // The amount must be less than `MAX_ALIGNABLE_AMOUNT` otherwise we'll overflow trying to align it, ending up with a\n    // nonsensical value.\n    assert!(\n        amount <= MAX_ALIGNABLE_AMOUNT,\n        \"`amount` must be less than `MAX_ALIGNABLE_AMOUNT`\"\n    );\n\n    amount.div_ceil(SERIALIZER_ALIGNMENT) * SERIALIZER_ALIGNMENT\n}\n\n/// Gets the maximum possible data file size given the type-level numerical limits and buffer invariants.\nfn get_maximum_data_file_size() -> u64 {\n    let ledger_len: u64 = LEDGER_LEN\n        .try_into()\n        .expect(\"Ledger length cannot be greater than `u64`.\");\n    (u64::MAX - ledger_len) / 2\n}\n\n/// Gets the minimum buffer size for the given maximum data file size.\n///\n/// This ensures that we are allowed to store enough bytes on-disk, as the buffer design requires being able to always\n/// write to a minimum number of data files, etc. This allow ensures that we're accounting for non-data file disk usage\n/// so that we do not overrun the specified maximum buffer size when considering the sum total of files placed on disk.\nfn get_minimum_buffer_size(max_data_file_size: u64) -> Option<u64> {\n    // We're doing this fallible conversion back-and-forth because we have to interoperate with `u64` and `usize`, and\n    // we need to ensure we're not getting values that can't be represented correctly in both types, as well as ensuring\n    // we're not implicitly overflowing and generating nonsensical numbers.\n    let ledger_len = LEDGER_LEN\n        .try_into()\n        .expect(\"Ledger length cannot be greater than `u64`.\");\n\n    // 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\n    // files at their maximum allowed size, plus an allowance for the size of the ledger state itself.","sourceCodeStart":82,"sourceCodeEnd":118,"githubUrl":"https://github.com/vectordotdev/vector/blob/3708c39b12a93212ed8b8d7510b4cc7769cb5864/lib/vector-buffers/src/variants/disk_v2/common.rs#L82-L118","documentation":"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.","triggerScenarios":"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.","commonSituations":"None; the value is baked in at compile time and is a few hundred bytes at most.","solutions":["No action possible or needed; if it ever appears, report it as an upstream bug"],"exampleFix":null,"handlingStrategy":"validation","validationCode":null,"typeGuard":null,"tryCatchPattern":null,"preventionTips":["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"],"tags":["rust","vector","disk-buffer","invariant","integer-conversion","panic"],"backgroundTag":"integer-width-conversion-panic","analyzedSha":"3708c39b12a93212ed8b8d7510b4cc7769cb5864","analyzedAt":"2026-08-20T07:02:18.786Z","contentChangedAt":null,"schemaVersion":2},"datasetVersion":"2026-09-08T20:17:18.057Z"}