BoundaryML/baml · error · LimitsError

all ingress capacities and the response reservation must be

Error message

all ingress capacities and the response reservation must be non-zero

What it means

`LimitsError::ZeroCapacity` from `IngressLimits::validate`. All ingress capacities (item counts and byte capacities, including read capacity) and the single-response byte reservation must be strictly greater than zero; a zero anywhere makes the limits configuration unusable, so validation fails.

Source

Thrown at baml_language/crates/baml_lsp_server/src/lsp_ingress.rs:260

        Self {
            normal_items: 256,
            normal_bytes: 4 * 1024 * 1024,
            reserved_items: 64,
            reserved_bytes: 2 * 1024 * 1024,
            read_items: 128,
            read_bytes: 2 * 1024 * 1024,
            control_items: 64,
            control_bytes: 64 * 1024,
            outbound_response_items: 256,
            outbound_response_bytes: 4 * 1024 * 1024,
            response_reservation_bytes: 16 * 1024,
        }
    }
}

#[derive(Debug, Clone, PartialEq, Eq, thiserror::Error)]
pub enum LimitsError {
    #[error("all ingress capacities and the response reservation must be non-zero")]
    ZeroCapacity,
    #[error("read capacity must fit inside normal capacity")]
    ReadExceedsNormal,
    #[error("one response reservation must fit in the outbound byte capacity")]
    ResponseReservationTooLarge,
    #[error("combined normal and reserved capacity overflowed usize")]
    CapacityOverflow,
}

impl IngressLimits {
    fn validate(self) -> Result<Self, LimitsError> {
        if self.normal_items == 0
            || self.normal_bytes == 0
            || self.reserved_items == 0
            || self.reserved_bytes == 0
            || self.read_items == 0
            || self.read_bytes == 0
            || self.control_items == 0

View on GitHub (pinned to bd85ce9dee)

Solutions

  1. Set every capacity and the response reservation to a positive value
  2. If you meant 'unbounded', use the designated unbounded constructor/option instead of 0
  3. Validate limits at startup so a zero fails fast with a clear config error
  4. Audit where limit values come from (config file/env) and clamp zeros to safe defaults

Example fix

// before
let limits = IngressLimits::new(0, 1 << 20, 1 << 12, 1 << 10)?;

// after
let limits = IngressLimits::new(64, 1 << 20, 1 << 12, 1 << 10)?;
Defensive patterns

Strategy: validation

Validate before calling

fn limits_ok(l: &IngressLimits) -> bool {
    l.normal_items > 0 && l.normal_bytes > 0 && l.read_bytes > 0 && l.response_reservation > 0
}

Try / catch

let limits = IngressLimits::new(a, b, c, d)
    .map_err(|e| match e { LimitsError::ZeroCapacity => ConfigError::new("capacities must be > 0"), other => other.into() })?;

Prevention

When it happens

Trigger: Constructing `IngressLimits` with `normal_items == 0`, zero normal byte capacity, zero read capacity, or a zero response reservation, then calling `validate()` (explicitly or via the constructor path).

Common situations: Deriving limits from a config value of 0 (e.g. 'unlimited = 0' convention colliding with 'must be non-zero'); copy-pasting a limits literal and leaving a zero field; a caller disabling a channel by zeroing its capacity.

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 BoundaryML/baml@bd85ce9dee (2026-09-12). Data as JSON: /api/errors/a213a590c66cde26. Report an issue: GitHub.