jdx/mise · error
remote cache blob packs require a positive max_pack_bytes…
Error message
remote cache blob packs require a positive max_pack_bytes limit
What it means
If a server advertises blob-pack support but its limits block declares max_pack_bytes == 0, the client treats the capability document as malformed and fails. A zero byte limit means the negotiated pack size is unusable, so the client refuses to use blob packs with such a configuration. The sibling check enforces the same for max_batch_items.
Solutions
- Fix the server configuration so limits.max_pack_bytes is a positive byte value
- If the server misconfig cannot be fixed promptly, disable blob packs on the client side or rely on the single-blob endpoint (the capability fetch failure will surface here, so it must be fixed server-side)
- Verify the capabilities endpoint response with curl and confirm the limits block values
Example fix
// before (server capabilities)
limits: { max_batch_items: 100, max_pack_bytes: 0 }
// after
limits: { max_batch_items: 100, max_pack_bytes: 67108864 } Defensive patterns
Strategy: validation
Validate before calling
// Validate the capability document before relying on blob packs:
if caps.features.blob_packs
&& (caps.limits.max_pack_bytes == 0 || caps.limits.max_batch_items <= 0)
{
bail!("server advertises blob packs with unusable limits");
} Type guard
fn usable_pack_limits(c: &RemoteCacheCapabilities) -> bool {
!c.features.blob_packs || (c.limits.max_pack_bytes > 0 && c.limits.max_batch_items > 0)
} Prevention
- Set sane positive limits in the server's capability configuration and validate at startup
- Add a server-side startup assertion that advertised blob-pack limits are > 0
- Test the capabilities endpoint after every server config change
When it happens
Trigger: Calling get_blob_pack against a server whose capabilities JSON contains limits.max_pack_bytes = 0 (or a negative value) while features.blob_packs is true.
Common situations: Misconfigured server defaults (limits not initialized); a server bug emitting 0 limits; hand-edited or partially migrated server capability configuration.
Understand the failure class
Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.
Related errors
- task cache store version mismatch: local version
- brew-cask: command_wrapper
- cached rustc output directory has unsupported entries
- cannot encode # as JSON
- cli feature is not enabled
AI-assisted analysis of jdx/mise@533346cc37 (2026-09-17).
Data as JSON: /api/errors/34a83e5a14391080.
Report an issue: GitHub.
Appendix: source
Thrown at crates/mise-cache-core/src/lib.rs:504
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 533346cc37)