Request on table . with ttl of seconds exceeds maximum…

Error message

Request on table {}.{} with {}ttl of {} seconds exceeds maximum supported expiration date of {} and will have its expiration capped to that date. In order to avoid this use a lower TTL or upgrade to a version where this limitation is fixed. See CASSANDRA-14092 and CASSANDRA-14227 for more details.

What it means

Cassandra stores expirations as local seconds with a maximum representable deletion time (2038-related limit). When TTL + now exceeds that maximum, under the CAP policy the write proceeds but its expiration is capped at the max date, and a warning is sent to the client explaining the cap and pointing to CASSANDRA-14092/14227.

Solutions

Lower the TTL in the write or the table's default_ttl so ttl + now stays under the maximum expiration date.
Check cassandra.yaml expiration_date_overflow_policy; CAP_NOWARN silently caps if the warning noise is unwanted (data still capped).
Upgrade to a version where the expiration-date limitation is fixed (per CASSANDRA-14092/CASSANDRA-14227).

Example fix

// before
INSERT INTO ks.t (k, v) VALUES (1, 'x') USING TTL 2147483647;
// after
INSERT INTO ks.t (k, v) VALUES (1, 'x') USING TTL 630720000; // 20 years

Defensive patterns

Strategy: validation

Validate before calling

long maxDeletionTime = Cell.getVersionedMaxDeletiontionTime();
long nowInSecs = System.currentTimeMillis() / 1000;
if (ttl + nowInSecs > maxDeletionTime) {
    ttl = (int) Math.max(0, maxDeletionTime - nowInSecs); // clamp before write
}

Prevention

Clamp application-side TTLs before writing; avoid sentinel TTLs like Integer.MAX_VALUE.
Audit default_ttl table settings periodically.
Track time-to-2038 exposure for long-lived TTL data and plan upgrades.

When it happens

Trigger: Any write (INSERT/UPDATE with USING TTL, or default table TTL) where (long) ttl + nowInSecs exceeds Cell.getVersionedMaxDeletiontionTime() while expirations overflow policy is CAP; large TTLs (e.g. > ~20 years) or large default_ttl table settings.

Common situations: Tables configured with very high default_ttl; applications writing 'infinite' TTLs like TTL 2147483647; clusters approaching the 2038 ceiling as time passes.

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 apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/f7e5ae4ac31b6342. Report an issue: GitHub.

Appendix: source

Thrown at src/java/org/apache/cassandra/db/ExpirationDateOverflowHandling.java:88

    public static final String MAXIMUM_EXPIRATION_DATE_EXCEEDED_REJECT_MESSAGE = "Request on table %s.%s with %sttl of %d seconds exceeds maximum supported expiration " +
                                                                                 "date of %s. In order to avoid this use a lower TTL, change " +
                                                                                 "the expiration date overflow policy or upgrade to a version where this limitation " +
                                                                                 "is fixed. See CASSANDRA-14092 and CASSANDRA-14227 for more details.";

    public static void maybeApplyExpirationDateOverflowPolicy(TableMetadata metadata, int ttl, boolean isDefaultTTL) throws InvalidRequestException
    {
        if (ttl == BufferCell.NO_TTL)
            return;

        // Check for localExpirationTime overflow (CASSANDRA-14092) to apply a policy if needed
        long nowInSecs = currentTimeMillis() / 1000;
        if (((long) ttl + nowInSecs) > Cell.getVersionedMaxDeletiontionTime())
        {
            switch (policy)
            {
                case CAP:
                    ClientWarn.instance.warn(MessageFormatter.arrayFormat(MAXIMUM_EXPIRATION_DATE_EXCEEDED_WARNING, new Object[] { metadata.keyspace,
                                                                                                                                   metadata.name,
                                                                                                                                   isDefaultTTL? "default " : "",
                                                                                                                                   ttl,
                                                                                                                                   getMaxExpirationDateTS()})
                                                             .getMessage());
                case CAP_NOWARN:
                    /**
                     * Capping at this stage is basically not rejecting the request. The actual capping is done
                     * by {@link #computeLocalExpirationTime(long, int)}, which converts the negative TTL
                     * to {@link org.apache.cassandra.db.BufferExpiringCell#MAX_DELETION_TIME}
                     */
                    NoSpamLogger.log(logger, NoSpamLogger.Level.WARN, EXPIRATION_OVERFLOW_WARNING_INTERVAL_MINUTES, TimeUnit.MINUTES, MAXIMUM_EXPIRATION_DATE_EXCEEDED_WARNING,
                                     metadata.keyspace, metadata.name, isDefaultTTL? "default " : "", ttl, getMaxExpirationDateTS());
                    return;

                default:
                    throw new InvalidRequestException(String.format(MAXIMUM_EXPIRATION_DATE_EXCEEDED_REJECT_MESSAGE, metadata.keyspace, metadata.name,
                                                                    isDefaultTTL? "default " : "", ttl, getMaxExpirationDateTS()));

View on GitHub (pinned to 88fd0f6a0e)