apache/cassandra · warning

Write to %s.%s partition %s: %s (WriteWarningsSnapshot.write

Error message

Write to %s.%s partition %s: %s (WriteWarningsSnapshot.writeTombstoneWarnMessage(value))

What it means

CoordinatorWriteWarnings.processWarnings() reports per-table tombstone-write warnings. When mutations to a partition produced tombstones whose value exceeded the write-tombstone warning threshold, the coordinator emits 'Write to <ks>.<table> partition <key>: <detail>' as a client warning, logs it, and marks writeTombstoneWarnings. It signals expensive tombstone-generating writes.

Source

Thrown at src/java/org/apache/cassandra/service/writes/thresholds/CoordinatorWriteWarnings.java:161

        for (Map.Entry<TableId, Long> entry : snapshot.writeTombstone.tableValues.entrySet())
        {
            TableId tableId = entry.getKey();
            ColumnFamilyStore cfs = Schema.instance.getColumnFamilyStoreInstance(tableId);
            if (cfs == null)
            {
                logger.warn("ColumnFamilyStore is null for table {}, skipping", tableId);
                continue;
            }

            TableMetadata metadata = cfs.metadata();
            String partitionKey = metadata.partitionKeyType.toCQLString(warnings.partitionKey.getKey());
            String msg = String.format("Write to %s.%s partition %s: %s",
                                       metadata.keyspace,
                                       metadata.name,
                                       partitionKey,
                                       WriteWarningsSnapshot.writeTombstoneWarnMessage(entry.getValue()));
            ClientWarn.instance.warn(msg);
            logger.warn(msg);
            cfs.metric.writeTombstoneWarnings.mark();
        }
    }

    /**
     * Internal state holder for accumulated warnings.
     * A Mutation is always for a single partition key, so we store it once
     * and track warnings per table within that partition.
     */
    private static class Warnings
    {
        @Nullable
        DecoratedKey partitionKey;

        @Nullable
        WriteWarningsSnapshot snapshot;

View on GitHub (pinned to 88fd0f6a0e)

Solutions

  1. Stop using null-overwrites to delete; use explicit DELETEs and avoid patterns that generate tombstones
  2. Use TTLs and ensure compaction keeps pace; consider TimeWindowCompactionStrategy for TTL-heavy tables
  3. Raise the write tombstone warn threshold in cassandra.yaml if the tombstone volume is by design
  4. Locate the offending partition from the warning and adjust the client's write pattern

Example fix

// before: creates a tombstone per overwrite
UPDATE t SET col = null WHERE k = 1;
// after
delete col from t where k = 1; -- or drop the column usage entirely
Defensive patterns

Strategy: validation

Validate before calling

// avoid tombstone-generating writes at the app layer
if (isSettingColumnsToNull(statement))
    throw new IllegalArgumentException("Use DELETE instead of null-overwrite: " + cql);

Try / catch

ResultSet rs = session.execute(write);
for (String w : rs.getExecutionInfo().getWarnings())
    if (w.startsWith("Write to ") && w.contains("tombstone"))
        tombstoneAuditor.record(w);

Prevention

When it happens

Trigger: Writes (deletes, TTL expirations materialized, null/overwrites) generating tombstones above the write tombstone warn threshold on replicas, aggregated into WriteWarningsSnapshot and processed by the coordinator.

Common situations: Application deleting many rows/cells in one partition; overwriting columns with nulls (which create tombstones); high-churn workloads with frequent deletes.

Understand the failure class

Background: payload too large / request exceeds maximum size: why libraries cap bytes and how to fix oversize payloads — this error's family across 50 libraries.

Related errors


AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10). Data as JSON: /api/errors/0de72c876079f8ef. Report an issue: GitHub.