remote cache blob pack failed digest verification

Error message

remote cache blob pack failed digest verification

What it means

After streaming each blob payload, mise-cache-core hashes the bytes with the algorithm named in the entry header (blake3 or sha-256) and compares the result against the header digest. A mismatch aborts the whole pack. This is end-to-end integrity verification: either the bytes were corrupted in transit, or the server stored/served wrong bytes under that digest.

Source

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

        let path = directory.path().join(blobs.len().to_string());
        let mut output = tokio::fs::File::create(&path).await?;
        let mut remaining = digest.size;
        let mut buffer = [0_u8; 64 * 1024];
        while remaining > 0 {
            let limit = usize::try_from(remaining.min(buffer.len() as u64)).unwrap();
            let count = reader.read(&mut buffer[..limit]).await?;
            if count == 0 {
                bail!("remote cache blob pack ended before a blob was complete");
            }
            output.write_all(&buffer[..count]).await?;
            hasher.update(&buffer[..count]);
            remaining -= count as u64;
        }
        output.flush().await?;
        drop(output);
        if !hasher.matches(&digest.hash) {
            bail!("remote cache blob pack failed digest verification");
        }
        blobs.push((digest, path));
    }
    let blob_count = blobs.len().try_into().unwrap_or(u64::MAX);
    let metadata = metadata.validate(BlobPackResponseStats {
        blob_count,
        payload_bytes,
        framed_bytes,
    })?;
    Ok(DownloadedBlobPack {
        directory,
        blobs,
        metadata,
    })
}

enum BlobPackHasher {
    Blake3(Box<blake3::Hasher>),

View on GitHub (pinned to 6f52dcdf99)

Solutions

Switch the remote cache URL to HTTPS so intermediaries cannot modify bytes in transit.
On the server, re-verify stored blobs against their digests and evict mismatched objects so clients re-upload clean copies.
Retry once: in-flight corruption can be a one-off and the next pack re-downloads the affected blobs.
If it reproduces for one specific blob, delete that object server-side to force a fresh upload from a healthy client.

Defensive patterns

Strategy: retry

Try / catch

match remote_cache.download(staging_dir).await {
    Ok(pack) => Ok(pack),
    Err(err) if err.to_string().contains("failed digest verification") => {
        if url.scheme() != "https" { warn!("switch the cache to https"); }
        remote_cache.download(staging_dir).await // one retry; persistent mismatch = server blob corruption
    }
    other => other,
}

Prevention

Always use HTTPS for the remote cache URL so bodies cannot be modified in transit.
Run periodic server-side CAS verification to evict corrupt blobs.
Treat a reproducible mismatch for one digest as a server-side eviction request, not a client bug.

When it happens

Trigger: Downloading a blob pack over plain HTTP where an intermediary modified the body (the exact scenario `validate_remote_url` warns about); a server whose stored blob content is corrupt but still indexed under the original digest; header/payload misalignment from a framing error so payload bytes are hashed against the wrong header.

Common situations: Unencrypted HTTP remote cache on a shared network; server disk corruption silently serving bad bytes; middleboxes that rewrite or recompress response bodies.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

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