<warnings msg> with <loggableTokens> (client warning; msg fr

Error message

<warnings msg> with <loggableTokens> (client warning; msg from WarningsSnapshot warning message)

What it means

CoordinatorWarnings.recordWarnings() reports accumulated read-threshold WARNINGS from a WarningsSnapshot (e.g. tombstone warnings, large-row/cell warnings during reads). For each warning counter with instances, '<msg> with <loggableTokens>' is sent as a client warning, logged server-side, and the table metric is marked. It indicates a read is expensive but was still served.

Source

Thrown at src/java/org/apache/cassandra/service/reads/thresholds/CoordinatorWarnings.java:141

    }

    private static void recordAborts(WarningsSnapshot.Warnings counter, String cql, String loggableTokens, TableMetrics.TableMeter metric, ToString toString)
    {
        if (!counter.aborts.instances.isEmpty())
        {
            String msg = toString.apply(counter.aborts.instances.size(), counter.aborts.maxValue, cql);
            ClientWarn.instance.warn(msg + " with " + loggableTokens);
            logger.warn(msg);
            metric.mark();
        }
    }

    private static void recordWarnings(WarningsSnapshot.Warnings counter, String cql, String loggableTokens, TableMetrics.TableMeter metric, ToString toString)
    {
        if (!counter.warnings.instances.isEmpty())
        {
            String msg = toString.apply(counter.warnings.instances.size(), counter.warnings.maxValue, cql);
            ClientWarn.instance.warn(msg + " with " + loggableTokens);
            logger.warn(msg);
            metric.mark();
        }
    }

    /**
     * Utility class to create an immutable map which does not fail on mutation but instead ignores it.
     */
    private static final class IgnoreMap extends AbstractMap<Object, Object>
    {
        private static final IgnoreMap INSTANCE = new IgnoreMap();

        private static <K, V> Map<K, V> get()
        {
            return (Map<K, V>) INSTANCE;
        }

        @Override

View on GitHub (pinned to 88fd0f6a0e)

Solutions

Refine the query to narrow partitions scanned
Run compaction and clean up tombstone buildup
Raise the corresponding warning threshold in cassandra.yaml only if the cost is understood and acceptable
Use the logged message (count, max value, CQL) to find and fix the offending query pattern

Defensive patterns

Strategy: validation

Validate before calling

// check read scope before executing
if (!cql.contains("WHERE") || !cql.matches(".*\\s=?\\s*<partitionKey>.*"))
    logger.warn("Broad read may exceed warning thresholds: {}", cql);

Try / catch

ResultSet rs = session.execute(cql);
for (String w : rs.getExecutionInfo().getWarnings()) {
    if (w.contains("tombstone") || w.contains("warning"))
        log.warn("Coordinator read warning: {}", w);
}

Prevention

Design tables to avoid wide scans
Track read-warning metrics per table
Tune warn thresholds deliberately, not to silence

When it happens

Trigger: A query crossed a read warning threshold (e.g. more tombstones/rows touched than tombstone_warn_threshold, or row-size limits) on replicas; the coordinator aggregates the snapshot and emits the client warning via processWarnings().

Common situations: ALLOW FILTERING or broad partition scans touching many tombstones; tables with heavy TTL/delete churn; queries hitting many SSTables.

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/d8ba261ac0aa114d. Report an issue: GitHub.