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
- Stop using null-overwrites to delete; use explicit DELETEs and avoid patterns that generate tombstones
- Use TTLs and ensure compaction keeps pace; consider TimeWindowCompactionStrategy for TTL-heavy tables
- Raise the write tombstone warn threshold in cassandra.yaml if the tombstone volume is by design
- 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
- Never overwrite with nulls to delete values
- Prefer TTL over explicit deletes for expiring data
- Ensure compaction keeps pace with delete churn
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
- <warnings msg> with <loggableTokens> (client warning; msg fr
- <warnings msg> with <loggableTokens> (client warning; msg fr
- Write to %s.%s partition %s: %s (WriteWarningsSnapshot.write
- write_tombstone_warn_threshold (%d) must be -1 (disabled) or
- write_tombstone_warn_threshold (%d) cannot be less than min_
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/0de72c876079f8ef.
Report an issue: GitHub.