What causes "service limit values must be greater than 0" in influxdata/influxdb?

Inspect the limit value being converted and change it to a positive integer (>= 1).

influxdata/influxdb · error · ServiceLimitError

service limit values must be greater than 0

Error message

service limit values must be greater than 0

What it means

`ServiceLimitError::MustBeGreaterThanZero` is raised when converting a raw value into a service limit (`ServiceLimitUpdate`) and the supplied value is negative or zero. Service limits define per-database/per-table maximums (e.g. max tables, max columns per table), and zero or negative values would make the limit meaningless. The library rejects such values at conversion time rather than at query time.

Solutions

Inspect the limit value being converted and change it to a positive integer (>= 1).
If 'no limit' was intended, omit the field (use None) instead of passing 0, so `NoValueSpecified`/no-op semantics apply.
Fix the source configuration (config file, environment, or API payload) that produced the 0/negative value.
If the value is computed, add a floor/clamp so the computed limit is always > 0 before conversion.

Example fix

// before
ServiceLimitUpdate::MaxTables(0)
// after
ServiceLimitUpdate::MaxTables(100) // any value > 0

Defensive patterns

Strategy: validation

Validate before calling

fn validate_limit(v: usize) -> Result<usize, String> {
    if v == 0 { Err("service limit values must be greater than 0".into()) } else { Ok(v) }
}

Try / catch

match ServiceLimitUpdate::try_from(raw) {
    Err(ServiceLimitError::MustBeGreaterThanZero) => log::warn!("limit <= 0 rejected; using default"),
    Ok(u) => apply(u),
    Err(e) => return Err(e.into()),
}

Prevention

Never use 0 as a sentinel for 'no limit' — omit the field instead
Clamp computed limits with `.max(1)` before conversion
Validate limit config at startup, before applying updates

When it happens

Trigger: Calling a service-limit conversion/update API (e.g. `ServiceLimitUpdate::try_from` style conversions in `service_limits.rs`) with a value <= 0, such as passing 0 for max_tables or max_columns_per_table in a limit update request.

Common situations: Misconfigured cluster or database limit settings loaded from config or protobuf where defaults were left at 0; programmatic limit updates that compute a limit as 0 (e.g. an empty multiplication or a failed subtraction); users specifying 'no limit' as 0 instead of omitting the field.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

AI-assisted analysis of influxdata/influxdb@06200ef96b (2026-09-19). Data as JSON: /api/errors/9bfc01f6f14e9a9c. Report an issue: GitHub.

Appendix: source

Thrown at core/data_types/src/service_limits.rs:223

    }
}

/// Updating one, but not both, of the limits is what the UpdateNamespaceServiceProtectionLimit
/// gRPC request supports, so match that encoding on the Rust side.
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum ServiceLimitUpdate {
    /// Requesting an update to the maximum number of tables allowed in this namespace
    MaxTables(MaxTables),
    /// Requesting an update to the maximum number of columns allowed in each table in this
    /// namespace
    MaxColumnsPerTable(MaxColumnsPerTable),
}

/// Errors converting from raw values to the service limits
#[derive(Error, Debug, Clone, Copy)]
pub enum ServiceLimitError {
    /// A negative or 0 value was specified; those aren't allowed
    #[error("service limit values must be greater than 0")]
    MustBeGreaterThanZero,

    /// No value was provided so we can't update anything
    #[error("a supported service limit value is required")]
    NoValueSpecified,

    /// Limits are stored as `i32` in the database and transferred as i32 over protobuf, so even
    /// though they are stored as `usize` in Rust, the `usize` value must be less than `i32::MAX`.
    #[error("service limit values must fit in a 32-bit signed integer (`i32`)")]
    MustFitInI32,

    /// Per-table column limits are restricted
    #[error(
        "per-table column limits are restricted to a maximum value of {0} for system performance purposes"
    )]
    ColumnLimitTooLarge(MaxColumnsPerTable),
}

View on GitHub (pinned to 06200ef96b)