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 == 0View on GitHub (pinned to bd85ce9dee)
Solutions
- Set every capacity and the response reservation to a positive value
- If you meant 'unbounded', use the designated unbounded constructor/option instead of 0
- Validate limits at startup so a zero fails fast with a clear config error
- 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
- Never encode 'unlimited' as 0; use explicit unbounded options
- Clamp config-sourced capacities to minimum 1
- Validate limits at startup, before wiring the ingress
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
- read capacity must fit inside normal capacity
- one response reservation must fit in the outbound byte capac
- combined normal and reserved capacity overflowed usize
- dependency name `{name}` is reserved
- {0}
AI-assisted analysis of BoundaryML/baml@bd85ce9dee (2026-09-12).
Data as JSON: /api/errors/a213a590c66cde26.
Report an issue: GitHub.