vercel/next.js · error

inline value type claims a byte value, over the byte maximum

Error message

inline value type {ty} claims a {size} byte value, over the {MAX_INLINE_VALUE_SIZE} byte maximum

What it means

turbo-persistence validates inline value entries in a key block: the entry's type byte encodes the inline value's size, and that size must not exceed MAX_INLINE_VALUE_SIZE. This error is thrown when decoding a block whose type byte claims an inline value larger than the format allows. It almost always indicates a corrupt, truncated, or hand-edited static sorted file rather than a caller bug.

Solutions

1. Delete the corrupt cache directory (e.g. .next/cache or the turbo-persistence store path) and let it rebuild from scratch.
2. Verify disk health / free space and check for processes that interrupted writes.
3. If it reproduces after rebuild, report it: it may be an internal-invariant violation in the writer or a format-version mismatch; align Next.js/Turbopack versions so reader and writer agree on the format.

// Before reading a persisted store, sanity-check the cache directory
import { statSync } from 'fs'
function cacheLooksPlausible(dir: string): boolean {
  try {
    const s = statSync(dir)
    return s.isDirectory() && s.size >= 0
  } catch {
    return false
  }
}
// If false or decode fails, delete the dir and rebuild instead of retrying reads.

try {
  openStaticSortedFile(path)
} catch (e) {
  if (String(e).includes('inline value type')) {
    rmSync(cacheDir, { recursive: true, force: true })
    // rebuild cache
  } else throw e
}

When it happens

Trigger: Decoding a key block entry whose type byte is >= KEY_BLOCK_ENTRY_TYPE_INLINE_MIN and where (ty - KEY_BLOCK_ENTRY_TYPE_INLINE_MIN) exceeds MAX_INLINE_VALUE_SIZE; typically reached while opening/reading a persisted static sorted file with corrupted or out-of-format bytes.

Common situations: Corrupted on-disk cache (disk full, crash mid-write, bit rot), a stale cache directory written by an incompatible turbo-persistence version, or manual tampering with cache files.

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

• mixed-type fixed key block claims a
• mixed-type fixed key block too short
• block of .sst is the last block but not an index block…
• fixed key block for entries is the wrong size
• fixed key block too short

AI-assisted analysis of vercel/next.js@34433fd12e (2026-09-20). Data as JSON: /api/errors/c8c1c7669c520f72. Report an issue: GitHub.

Appendix: source

Thrown at turbopack/crates/turbo-persistence/src/static_sorted_file.rs:1628

fn entry_val_size(ty: u8) -> Result<usize> {
    match ty {
        KEY_BLOCK_ENTRY_TYPE_SMALL => Ok(SMALL_VALUE_REF_SIZE),
        KEY_BLOCK_ENTRY_TYPE_MEDIUM => Ok(MEDIUM_VALUE_REF_SIZE),
        KEY_BLOCK_ENTRY_TYPE_BLOB => Ok(BLOB_VALUE_REF_SIZE),
        KEY_BLOCK_ENTRY_TYPE_KEY_DELETED => Ok(KEY_DELETED_REF_SIZE),
        // Must precede the inline arm: both are open-ended and the tombstone range sits above it.
        ty if ty >= KEY_BLOCK_ENTRY_TYPE_KEY_VALUE_DELETED_MIN => {
            let size = (ty - KEY_BLOCK_ENTRY_TYPE_KEY_VALUE_DELETED_MIN) as usize;
            ensure!(
                size <= MAX_INLINE_VALUE_SIZE,
                "key-value tombstone type {ty} claims a {size} byte value, over the \
                 {MAX_INLINE_VALUE_SIZE} byte maximum"
            );
            Ok(size)
        }
        ty if ty >= KEY_BLOCK_ENTRY_TYPE_INLINE_MIN => {
            let size = (ty - KEY_BLOCK_ENTRY_TYPE_INLINE_MIN) as usize;
            ensure!(
                size <= MAX_INLINE_VALUE_SIZE,
                "inline value type {ty} claims a {size} byte value, over the \
                 {MAX_INLINE_VALUE_SIZE} byte maximum"
            );
            Ok(size)
        }
        _ => bail!("Invalid key block entry type: {ty}"),
    }
}

/// Reads the type and start offset from an offset table entry.
///
/// The trailing 4 bytes of every entry pack 1 byte of type into the top of a 3-byte BE offset.
/// `HashThenKey` entries carry the key's 8-byte hash ahead of that word — see
/// [`KEY_BLOCK_TABLE_ENTRY_SIZE_WITH_HASH`].
#[inline(always)]
fn read_offset_entry(
    offsets: &[u8],

View on GitHub (pinned to 34433fd12e)