jdx/mise · error
remote cache blob packs require a positive max_pack_bytes li
Error message
remote cache blob packs require a positive max_pack_bytes limit
What it means
Thrown while parsing server capabilities (crates/mise-cache-core/src/lib.rs:548): the server advertises features.blob_packs but sets limits.max_pack_bytes == 0. A zero byte limit would make every pack request invalid, so the client treats it as a misconfiguration rather than a usable limit. (Compare the sibling check at lib.rs:541 requiring max_batch_items to be positive.)
Source
Thrown at crates/mise-cache-core/src/lib.rs:548
let capabilities: RemoteCacheCapabilities =
response.error_for_status()?.json().await?;
if capabilities.protocol.major != PROTOCOL_VERSION {
bail!(
"remote cache capability protocol {} is incompatible with client protocol {PROTOCOL_VERSION}",
capabilities.protocol.major
);
}
if !capabilities.features.blob_packs {
return Ok(None);
}
let max_items = usize::try_from(capabilities.limits.max_batch_items)
.ok()
.filter(|limit| *limit > 0)
.ok_or_else(|| {
eyre!("remote cache blob packs require a positive max_batch_items limit")
})?;
if capabilities.limits.max_pack_bytes == 0 {
bail!("remote cache blob packs require a positive max_pack_bytes limit");
}
Ok(Some(BlobPackLimits {
max_items: max_items.min(MAX_STAGED_BLOB_PACK_ITEMS),
max_bytes: capabilities
.limits
.max_pack_bytes
.min(MAX_STAGED_BLOB_PACK_BYTES),
}))
})
.await
.copied()
}
/// Download verified CAS objects using the server's negotiated blob-pack extension.
///
/// `None` means the server does not support blob packs. Objects omitted by a
/// supported server are absent from `blobs`, so callers can retry them through
/// the ordinary single-blob endpoint.View on GitHub (pinned to 6f52dcdf99)
Solutions
- If you operate the server, set a positive max_pack_bytes limit in the capabilities response (the client will additionally clamp it to MAX_STAGED_BLOB_PACK_BYTES = 256 MiB)
- If the server cannot serve packs correctly, disable the feature: features.blob_packs = false — the client then returns Ok(None) and uses per-blob downloads
- If you do not control the server, report the misconfiguration; the client intentionally refuses rather than send packs it knows will be rejected
Defensive patterns
Strategy: fallback
Validate before calling
let caps: RemoteCacheCapabilities = fetch_capabilities(&url).await?;
let packs_usable = caps.features.blob_packs
&& caps.limits.max_batch_items > 0
&& caps.limits.max_pack_bytes > 0;
if !packs_usable { /* use per-blob path from the start */ } Type guard
fn blob_packs_configured(c: &RemoteCacheCapabilities) -> bool {
c.features.blob_packs && c.limits.max_batch_items > 0 && c.limits.max_pack_bytes > 0
} Try / catch
if !blob_packs_configured(&caps) { client.disable_blob_packs(); }
// subsequent pack calls are avoided entirely; per-blob GETs are used Prevention
- Validate the capabilities document in your server's test suite: enabling blob_packs obligates positive limits
- Default limits to concrete values server-side rather than serde defaults of 0
- Smoke-test client+server pairs on version bumps
When it happens
Trigger: The capabilities endpoint returns {"features":{"blob_packs":true},"limits":{"max_batch_items":N,"max_pack_bytes":0}}. Typical for a half-configured or custom cache server that enables the feature flag but leaves the size limit unset/defaulted to zero.
Common situations: Server-side config omission (limit field not set, serde default 0); a server template/example copied with the limits block empty; version skew where the field name changed and serde deserialized the default.
Related errors
- remote cache blob pack content length metadata mismatch: exp
- remote cache blob pack blob count metadata mismatch: expecte
- remote cache blob pack payload byte metadata mismatch: expec
- remote cache capability protocol {} is incompatible with cli
- remote cache blob pack has an invalid content type
AI-assisted analysis of jdx/mise@6f52dcdf99 (2026-08-22).
Data as JSON: /api/errors/34a83e5a14391080.
Report an issue: GitHub.