apache/seatunnel · error · IllegalArgumentException

start_mode.timestamp must not be greater than the current ti

Error message

start_mode.timestamp must not be greater than the current time

What it means

When start_mode=TIMESTAMP, KafkaSourceConfig validates at consumer-metadata creation that start_mode.timestamp is not in the future. Since consumption starts from offsets at that timestamp, a future time is meaningless and would yield no offsets, so an IllegalArgumentException is thrown.

Source

Thrown at seatunnel-connectors-v2/connector-kafka/src/main/java/org/apache/seatunnel/connectors/seatunnel/kafka/source/KafkaSourceConfig.java:215

        consumerMetadata.setCatalogTable(outputCatalogTable);
        consumerMetadata.setDeserializationSchema(schema);

        // parse start mode
        readonlyConfig
                .getOptional(START_MODE)
                .ifPresent(
                        startMode -> {
                            consumerMetadata.setStartMode(startMode);
                            switch (startMode) {
                                case TIMESTAMP:
                                    long startOffsetsTimestamp =
                                            readonlyConfig.get(START_MODE_TIMESTAMP);
                                    long currentTimestamp = System.currentTimeMillis();
                                    // Runtime check: cannot be declarative (depends on current
                                    // time)
                                    if (startOffsetsTimestamp > currentTimestamp) {
                                        throw new IllegalArgumentException(
                                                "start_mode.timestamp must not be greater than the current time");
                                    }
                                    consumerMetadata.setStartOffsetsTimestamp(
                                            startOffsetsTimestamp);
                                    if (Objects.nonNull(
                                            readonlyConfig.get(START_MODE_END_TIMESTAMP))) {
                                        long endOffsetsTimestamp =
                                                readonlyConfig.get(START_MODE_END_TIMESTAMP);
                                        // Runtime check: cannot be declarative (depends on current
                                        // time)
                                        if (endOffsetsTimestamp > currentTimestamp) {
                                            throw new IllegalArgumentException(
                                                    "start_mode.end_timestamp must not be greater than the current time");
                                        }
                                        consumerMetadata.setEndOffsetsTimestamp(
                                                endOffsetsTimestamp);
                                    }
                                    break;

View on GitHub (pinned to cf67b549a7)

Solutions

1. Set start_mode.timestamp to a past epoch-millis value (System.currentTimeMillis() computed at job submission or earlier).
2. Compute the timestamp dynamically at job start instead of hardcoding it.
3. Verify the value is in milliseconds (13-digit for recent dates), not seconds.

Example fix

// before
start_mode.timestamp = 1893456000000  # 2030-01-01, in the future
// after
start_mode.timestamp = 1704067200000  # 2024-01-01, in the past

long ts = config.getStartModeTimestamp();
if (ts > System.currentTimeMillis()) throw new IllegalArgumentException("start_mode.timestamp must be in the past (epoch millis)");

try { submitJob(cfg); } catch (IllegalArgumentException e) { if (e.getMessage().contains("start_mode.timestamp")) fixTimestamp(cfg); else throw e; }

When it happens

Trigger: Setting start_mode=TIMESTAMP with start_mode.timestamp = System.currentTimeMillis() computed later in the config chain, or any hardcoded timestamp greater than current wall-clock time when createConsumerMetadata runs.

Common situations: Timestamps generated at build/codegen time but job launched later; copy-pasted future dates; timezone confusion (e.g. interpreting local time as epoch millis incorrectly); clock skew on the submitting host.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors

• start_mode.end_timestamp must not be greater than the curren
• start_timestamp can't be negative
• end_timestamp can't be negative
• start_timestamp must be less than end_timestamp
• tables_configs[%d]: 'start_mode.timestamp' must be >= 0, got

AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/6471151d26045201. Report an issue: GitHub.