What causes "original size does not fit usize" in BoundaryML/baml?

Validate/repair the writer to never emit negative or absurd original_size_bytes values

original size does not fit usize

Error message

original size does not fit usize

What it means

ValueMetadataV1.original_size_bytes is an i64/u64 in proto, and when present it is converted to usize. If the stored value is negative or exceeds the platform usize (e.g. > u64::MAX on 32-bit, or a negative value), usize::try_from fails and the record conversion returns InvalidData with this message.

Source

Thrown at baml_language/crates/bex_events/src/value/record.rs:183

            crate::value::pb::ValueAvailability::Omitted => ValueAvailability::Omitted,
            crate::value::pb::ValueAvailability::Lost => ValueAvailability::Lost,
            crate::value::pb::ValueAvailability::Unspecified => {
                return Err(io::Error::new(
                    io::ErrorKind::InvalidData,
                    "value metadata omitted availability",
                ));
            }
        };
        Ok(Self {
            id: metadata.id,
            codec,
            availability,
            original_size_bytes: metadata
                .original_size_bytes
                .map(usize::try_from)
                .transpose()
                .map_err(|_| {
                    io::Error::new(
                        io::ErrorKind::InvalidData,
                        "original size does not fit usize",
                    )
                })?,
            retained_size_bytes: metadata
                .retained_size_bytes
                .map(usize::try_from)
                .transpose()
                .map_err(|_| {
                    io::Error::new(
                        io::ErrorKind::InvalidData,
                        "retained size does not fit usize",
                    )
                })?,
            diagnostic: metadata.diagnostic,
        })
    }
}

View on GitHub (pinned to bd85ce9dee)

Solutions

Validate/repair the writer to never emit negative or absurd original_size_bytes values
Read the trace on a 64-bit platform if the values are legitimately large
Treat sizes > a sane bound as corruption and skip the record at ingest
Sanitize the proto before conversion (clamp or None-out implausible sizes)

Example fix

// before
let size = md.original_size_bytes.unwrap_or_default(); // i64 may be negative
// after
let size = md.original_size_bytes.filter(|s| *s >= 0 && (*s as u64) <= usize::MAX as u64);

Defensive patterns

Strategy: type-guard

Validate before calling

fn size_fits(v: Option<i64>) -> bool { v.map_or(true, |s| s >= 0 && (s as u64) <= usize::MAX as u64) }

Type guard

fn valid_original_size(md: &pb::ValueMetadataV1) -> bool { md.original_size_bytes.map_or(true, |s| s >= 0) }

Try / catch

ValueRecord::try_from(md).map_err(|e| if e.to_string().contains("original size") { CorruptionKind::BadSize.into() } else { e })

Prevention

Never use negative sentinels for sizes in protos
Sanity-check sizes against a max bound before writing
Test readers on the smallest target platform (32-bit) if supported

When it happens

Trigger: Decoding a ValueMetadataV1 whose original_size_bytes is negative (corruption, bit-flip, signed/unsigned writer bug) or larger than usize::MAX on a 32-bit target.

Common situations: 32-bit builds reading traces written on 64-bit machines with huge declared sizes, corrupted/truncated files, or writer bugs storing sentinel values like -1.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/887dc646150044ee. Report an issue: GitHub.