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

  1. Fix the server configuration so limits.max_pack_bytes is a positive byte value
  2. 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)
  3. 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

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


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)