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

  1. 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)
  2. 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
  3. 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

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


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