influxdata/influxdb · error · ServiceLimitError

service limit values must fit in a 32-bit signed integer…

Error message

service limit values must fit in a 32-bit signed integer (`i32`)

What it means

`ServiceLimitError::MustFitInI32` is raised when a limit value stored as `usize` in Rust exceeds `i32::MAX`. Limits are persisted as `i32` in the database and transferred as `i32` over protobuf, so any larger `usize` cannot be represented and would silently truncate or overflow. The library rejects it explicitly during conversion.

Solutions

Reduce the limit value to <= `i32::MAX` before conversion.
If the intent is 'unlimited', use the appropriate sentinel/omission mechanism supported by the schema instead of a huge number.
Use `usize::try_from`/checked conversions with a clamp to `i32::MAX` when computing limits.
Check for accidental overflow in the code that computes the limit.

Example fix

// before
let limit: usize = usize::MAX; // sentinel for unlimited
// after
let limit: usize = 2_147_483_647.min(usize::MAX); // must fit i32

Defensive patterns

Strategy: validation

Validate before calling

fn fits_i32(v: usize) -> bool { v <= i32::MAX as usize }

Try / catch

let limit = i32::try_from(usize_limit)
    .map_err(|_| ServiceLimitError::MustFitInI32)?;

Prevention

Use `i32::try_from` on every usize->i32 limit conversion
Avoid huge sentinel values for 'unlimited'; use schema-supported omission
Use checked arithmetic when computing limits to prevent overflow

When it happens

Trigger: Converting a service limit to its stored/protobuf representation with a `usize` value greater than `i32::MAX` (2,147,483,647), e.g. passing `usize::MAX` or a very large configured limit.

Common situations: Users setting 'unlimited' as a huge sentinel number; config values copied from 64-bit oriented systems; arithmetic that overflows (multiplying large limits); platform differences where `usize` is 64-bit but the wire format is 32-bit.

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/19483c0a604dc8a2. Report an issue: GitHub.

Appendix: source

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

    /// 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),
}

impl ServiceLimitUpdate {
    /// Constructs a [`ServiceLimitUpdate`] from the provided `limit_update`,
    /// performing validation and applying `column_limit_upper_bound` to the
    /// per-table column limit.
    pub fn bounded_try_from(
        limit_update: Option<LimitUpdate>,
        column_limit_upper_bound: MaxColumnsPerTable,
    ) -> Result<Self, ServiceLimitError> {
        match limit_update {

View on GitHub (pinned to 06200ef96b)