remote cache blob pack blob count metadata mismatch: expecte

Error message

remote cache blob pack blob count metadata mismatch: expected {}, decoded {}

What it means

Thrown while validating a blob-pack download (crates/mise-cache-core/src/lib.rs:330): the response's blob-count metadata header (BLOB_PACK_BLOBS_HEADER, parsed in from_headers) disagrees with blob_count — the number of blob records actually decoded from the pack stream. The server promised N blobs but the framed body contained a different count.

Source

Thrown at crates/mise-cache-core/src/lib.rs:330

            blob_count: optional_u64_header(headers, BLOB_PACK_BLOBS_HEADER)?,
            payload_bytes: optional_u64_header(headers, BLOB_PACK_BYTES_HEADER)?,
        })
    }

    fn validate(self, decoded: BlobPackResponseStats) -> Result<BlobPackResponseStats> {
        if let Some(content_length) = self.content_length
            && content_length != decoded.framed_bytes
        {
            bail!(
                "remote cache blob pack content length metadata mismatch: expected {}, decoded {}",
                content_length,
                decoded.framed_bytes
            );
        }
        if let Some(blob_count) = self.blob_count
            && blob_count != decoded.blob_count
        {
            bail!(
                "remote cache blob pack blob count metadata mismatch: expected {}, decoded {}",
                blob_count,
                decoded.blob_count
            );
        }
        if let Some(payload_bytes) = self.payload_bytes
            && payload_bytes != decoded.payload_bytes
        {
            bail!(
                "remote cache blob pack payload byte metadata mismatch: expected {}, decoded {}",
                payload_bytes,
                decoded.payload_bytes
            );
        }
        Ok(BlobPackResponseStats {
            blob_count: self.blob_count.unwrap_or(decoded.blob_count),
            payload_bytes: self.payload_bytes.unwrap_or(decoded.payload_bytes),
            framed_bytes: self.content_length.unwrap_or(decoded.framed_bytes),

View on GitHub (pinned to 6f52dcdf99)

Solutions

Retry the download — transient truncation or a server-side race often resolves itself
Fall back to per-blob downloads by disabling blob packs for this remote, then re-enable to test
Verify the response is not being modified in transit (compression, truncation) by proxies
If you control the server, compute the blob-count header from the exact byte stream serialized, under the same lock as pack generation

Defensive patterns

Strategy: retry

Try / catch

match client.get_blob_pack(&digests, &staging).await {
    Err(e) if e.to_string().contains("blob count metadata mismatch") => {
        client.get_blob_pack(&digests, &staging).await // one retry
            .or_else(|_| fallback_per_blob(&client, &digests))
    }
    other => other?,
}

Prevention

Retry once, then fall back to per-blob GETs which are independently digest-verified
If you run the server, generate pack headers and body under the same snapshot/lock
Track per-endpoint mismatch counts to distinguish transient races from systematic bugs

When it happens

Trigger: Calling the blob-pack download path (get_blob_pack -> decode_blob_pack at lib.rs:899) against a server whose blob-count header does not match the records in the body — e.g. the server added/removed a blob after computing the header, or the stream was cut short before the last records arrived (which would also shift framed_bytes).

Common situations: Server-side race between pack generation and concurrent blob uploads; a proxy truncating the response body; version skew between client and server pack formats; a custom cache server implementing the pack endpoint incorrectly.

Related errors

AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22). Data as JSON: /api/errors/e4e7b18da1e9a01b. Report an issue: GitHub.