elastic/elasticsearch · error · IllegalArgumentException

failed to parse value%s for setting [%s], must be lower than

Error message

failed to parse value%s for setting [%s], must be lower than setting [%s] which is [%s]

What it means

Thrown by DataStreamsPlugin.additionalLookAheadTimeValidation when index.look_ahead_time is set to a value greater than or equal to the cluster setting index.time_series.poll_interval. The look-ahead window must be strictly smaller than the poll interval so that successive time-series windows do not overlap incorrectly. The message names both settings and their values.

Source

Thrown at modules/data-streams/src/main/java/org/elasticsearch/datastreams/DataStreamsPlugin.java:203

        return extensions.isEmpty() ? fallback : extensions.get(0);
    }

    protected Clock getClock() {
        return Clock.systemUTC();
    }

    // The dependency of index.look_ahead_time is a cluster setting and currently there is no clean validation approach for this:
    static void additionalLookAheadTimeValidation(TimeValue lookAhead, TimeValue timeSeriesPollInterval) {
        if (lookAhead.compareTo(timeSeriesPollInterval) < 0) {
            final String message = String.format(
                Locale.ROOT,
                "failed to parse value%s for setting [%s], must be lower than setting [%s] which is [%s]",
                " [" + lookAhead.getStringRep() + "]",
                LOOK_AHEAD_TIME.getKey(),
                TIME_SERIES_POLL_INTERVAL.getKey(),
                timeSeriesPollInterval.getStringRep()
            );
            throw new IllegalArgumentException(message);
        }
    }

    @Override
    public List<Setting<?>> getSettings() {
        List<Setting<?>> pluginSettings = new ArrayList<>();
        pluginSettings.add(TIME_SERIES_POLL_INTERVAL);
        pluginSettings.add(LOOK_AHEAD_TIME);
        pluginSettings.add(LOOK_BACK_TIME);
        pluginSettings.add(DataStreamIndexSettingsProvider.SUPPORT_SEQ_NO_DISABLED);
        pluginSettings.add(DataStreamIndexSettingsProvider.SUPPORT_SYNTHETIC_ID);
        pluginSettings.add(DataStreamLifecycleService.DATA_STREAM_LIFECYCLE_POLL_INTERVAL_SETTING);
        pluginSettings.add(DataStreamLifecycleService.DATA_STREAM_MERGE_POLICY_TARGET_FLOOR_SEGMENT_SETTING);
        pluginSettings.add(DataStreamLifecycleService.DATA_STREAM_MERGE_POLICY_TARGET_FACTOR_SETTING);
        pluginSettings.add(DataStreamLifecycleService.DLM_CREATED_SETTING);
        pluginSettings.add(DataStreamLifecycleService.DATA_STREAM_MAX_DOWNSAMPLING_INDICES_IN_PROGRESS_SETTING);
        pluginSettings.add(TransportPastTimeSeriesIndexCreationAction.PAST_TSDB_INDEX_INTERVAL);
        return pluginSettings;

View on GitHub (pinned to db6a809a66)

Solutions

1. Lower index.look_ahead_time to a value strictly below index.time_series.poll_interval.
2. Or raise index.time_series.poll_interval above the configured look_ahead_time.
3. Re-apply the change with both values consistent, e.g. look_ahead_time=30s, poll_interval=1m.

Example fix

// before
PUT _cluster/settings
{"persistent":{"index.look_ahead_time":"2m","index.time_series.poll_interval":"1m"}}
// after
{"persistent":{"index.look_ahead_time":"30s","index.time_series.poll_interval":"1m"}}

// Validate look_ahead_time < time_series_poll_interval before applying.
function validateLookAhead(lookAheadMs, pollIntervalMs) {
  if (!(lookAheadMs < pollIntervalMs)) {
    throw new Error(`index.look_ahead_time (${lookAheadMs}ms) must be lower than index.time_series.poll_interval (${pollIntervalMs}ms)`);
  }
}

When it happens

Trigger: Configuring index.look_ahead_time >= index.time_series.poll_interval, e.g. look_ahead_time=2m with poll_interval=1m. The validation runs when the look-ahead setting is parsed/updated.

Common situations: Tuning tsdb ingestion bounds and forgetting the poll_interval constraint; changing poll_interval down without re-checking look_ahead_time; defaults overridden by a template.

Understand the failure class

• Parsing and encoding errors: unexpected token, malformed input — why parsers reject input and how to find the real culprit.

Related errors

• backing index [%s] in tsdb mode doesn't have the [%s] index
• Cannot create past TSDB backing index for data stream [{}] b
• Cannot add dynamic templates that define dimension fields on
• Cannot create past TSDB backing index for data stream [{}] w
• Expected at most one {} implementation, found: {}

AI-assisted analysis of elastic/elasticsearch@db6a809a66 (2026-08-12). Data as JSON: /api/errors/b1f2df64150b14a1. Report an issue: GitHub.