influxdata/influxdb · error · ServiceLimitError

a supported service limit value is required

Error message

a supported service limit value is required

What it means

`ServiceLimitError::NoValueSpecified` is raised when an update to a service limit is attempted but no value was supplied at all. Since there is nothing to convert or apply, the library cannot perform a meaningful update and rejects the request instead of silently no-oping.

Solutions

  1. Provide an explicit, supported limit value for the field you intend to update.
  2. If no update was intended, skip building the update entirely rather than constructing an empty one.
  3. Validate incoming request payloads server-side so missing limit fields are rejected before reaching the conversion.
  4. Check protobuf/config schemas to ensure the limit field is actually being populated.

Example fix

// before
let update = ServiceLimitUpdate::try_from(raw // value unset
)
// after
match raw.value {
    Some(v) => ServiceLimitUpdate::try_from(v)?,
    None => return Ok(()), // skip: nothing to update
}
Defensive patterns

Strategy: validation

Validate before calling

let value = raw.value.ok_or("a supported service limit value is required")?;

Try / catch

match raw.value {
    Some(v) => apply(ServiceLimitUpdate::try_from(v)?),
    None => return Err(ServiceLimitError::NoValueSpecified.into()),
}

Prevention

When it happens

Trigger: Constructing a `ServiceLimitUpdate`/conversion from a raw representation whose value field is absent (e.g. a protobuf `i32` limit field missing, or `None`/unset option passed to a limit-update conversion) in `service_limits.rs`.

Common situations: API clients sending partial limit-update requests where the intended field was accidentally omitted; protobuf messages decoded with unset optional limit fields; config parsing where a limit key is missing and the default is 'no value'.

Understand the failure class

Background: "missing required argument" and "the following required arguments were not provided": what required-argument errors mean and how to fix them — this error's family across 20 libraries.

Related errors

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

Appendix: source

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

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

impl ServiceLimitUpdate {
    /// Constructs a [`ServiceLimitUpdate`] from the provided `limit_update`,
    /// performing validation and applying `column_limit_upper_bound` to the
    /// per-table column limit.

View on GitHub (pinned to 06200ef96b)