rustfs/rustfs · error · ObjectDataCacheConfigError

object data cache ttl_secs must not exceed 2592000 seconds (

Error message

object data cache ttl_secs must not exceed 2592000 seconds (30 days)

What it means

ObjectDataCacheConfigError::TimeToLiveTooLarge fires when ttl exceeds MAX_DURATION_SECS = 2592000 (30 days). The cap bounds how long an entry can outlive configuration changes and restarts; extremely long TTLs also interact with moka's internal time arithmetic, so validate() (config.rs:208-210) rejects them.

Source

Thrown at crates/object-data-cache/src/error.rs:45

    /// The configured entry size exceeds the moka weigher's u32 accounting range.
    #[error("object data cache max_entry_bytes must stay below 4 GiB so the capacity weigher does not under-count entries")]
    MaxEntryBytesTooLarge,

    /// The configured entry size cannot fit inside the explicit byte capacity.
    #[error("object data cache max_entry_bytes plus weigher overhead must not exceed max_bytes")]
    MaxEntryBytesExceedsMaxBytes,

    /// The configured entry size exceeds the resolved (derived) cache capacity.
    #[error("object data cache max_entry_bytes must not exceed the resolved cache capacity")]
    MaxEntryBytesExceedsCapacity,

    /// The configured time-to-live cannot be zero.
    #[error("object data cache ttl_secs must be greater than 0")]
    ZeroTimeToLiveSecs,

    /// The configured time-to-live exceeds the supported upper bound.
    #[error("object data cache ttl_secs must not exceed 2592000 seconds (30 days)")]
    TimeToLiveTooLarge,

    /// The configured time-to-idle cannot be zero.
    #[error("object data cache time_to_idle_secs must be greater than 0")]
    ZeroTimeToIdleSecs,

    /// The configured time-to-idle exceeds the supported upper bound.
    #[error("object data cache time_to_idle_secs must not exceed 2592000 seconds (30 days)")]
    TimeToIdleTooLarge,

    /// The configured minimum free memory percentage exceeded the supported range.
    #[error("object data cache min_free_memory_percent must be in 1..=100")]
    InvalidMinFreeMemoryPercent,

    /// The configured fill concurrency per CPU exceeded the supported range.
    #[error("object data cache fill_concurrency_per_cpu must be greater than 0")]
    ZeroFillConcurrencyPerCpu,

View on GitHub (pinned to 35af688cd9)

Solutions

  1. Bring ttl to 2592000 seconds (30 days) or less; if data is effectively immutable, 30 days with re-fill on miss behaves nearly the same.
  2. Double-check the unit the config field expects (seconds) and convert your intended wall-clock time correctly.
  3. If you need permanent residency, evaluate whether an explicit capacity with time_to_idle serving as the reclamation mechanism meets the requirement.

Example fix

// before
ttl: Duration::from_secs(365 * 24 * 3600), // one year -> TimeToLiveTooLarge

// after
ttl: Duration::from_secs(30 * 24 * 3600), // 30 days, at the cap
Defensive patterns

Strategy: validation

Validate before calling

const MAX_DURATION_SECS: u64 = 2_592_000;
if cfg.ttl.as_secs() > MAX_DURATION_SECS {
    return Err(format!("ttl must not exceed {} seconds", MAX_DURATION_SECS));
}

Type guard

fn is_ttl_too_large(err: &ObjectDataCacheConfigError) -> bool {
    matches!(err, ObjectDataCacheConfigError::TimeToLiveTooLarge)
}

Try / catch

if let Err(ObjectDataCacheConfigError::TimeToLiveTooLarge) = cfg.validate() {
    // clamp ttl to <= 30 days; near-immutable data re-fills on miss anyway
}

Prevention

When it happens

Trigger: validate() with ttl.as_secs() > 2_592_000: e.g. setting a year-long TTL (31_536_000), or accidentally configuring seconds where days were intended (365 days entered as 31536000 seconds is fine, but '999999' style values cross the cap).

Common situations: 'Cache forever' intent expressed as a huge TTL instead of the appropriate mode; unit confusion (minutes vs seconds) inflating the value; copying a TTL from a system with no upper bound.

Related errors


AI-assisted analysis of rustfs/rustfs@35af688cd9 (2026-08-20). Data as JSON: /api/errors/7dbb3acf2147162d. Report an issue: GitHub.