apache/cassandra · warning
Write to %s.%s partition %s: %s (WriteWarningsSnapshot.write
Error message
Write to %s.%s partition %s: %s (WriteWarningsSnapshot.writeSizeWarnMessage(value))
What it means
CoordinatorWriteWarnings.processWarnings() reports per-table write-size warnings aggregated from replicas. When a written partition value exceeded the write-size warning threshold, a message 'Write to <ks>.<table> partition <key>: <detail>' is sent as a client warning, logged, and writeSizeWarnings metric is incremented. The write succeeded but was unusually large.
Source
Thrown at src/java/org/apache/cassandra/service/writes/thresholds/CoordinatorWriteWarnings.java:139
for (Map.Entry<TableId, Long> entry : snapshot.writeSize.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.writeSizeWarnMessage(entry.getValue()));
ClientWarn.instance.warn(msg);
logger.warn(msg);
cfs.metric.writeSizeWarnings.mark();
}
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,View on GitHub (pinned to 88fd0f6a0e)
Solutions
- Redesign the schema to split large partitions (bucketing keys, time buckets)
- Cap row/collection sizes at the application layer before writing
- Raise the write-size warning threshold in cassandra.yaml only deliberately
- Inspect the warning's partition key to find and fix the offending writer
Example fix
// before: one partition per user grows forever INSERT INTO events (user_id, ts, payload) VALUES (?, ?, ?); // after: bucket by day INSERT INTO events_by_day (user_id, day, ts, payload) VALUES (?, ?, ?, ?);
Defensive patterns
Strategy: validation
Validate before calling
// application-side partition size guard
if (estimatePartitionBytes(key) + pendingWriteBytes > writeSizeWarnThreshold)
throw new IllegalStateException("write would exceed partition size warning threshold for " + key); Try / catch
ResultSet rs = session.execute(write);
for (String w : rs.getExecutionInfo().getWarnings())
if (w.startsWith("Write to ")) partitionSizer.alert(w); Prevention
- Bound partition sizes with bucketed keys
- Avoid unbounded collections/rows per partition
- Alert on writeSizeWarnings metric
When it happens
Trigger: Mutations whose partition value (data written to a single partition key) exceeded the write_size warning threshold; the coordinator's next processWarnings call formats the message and warns the client.
Common situations: Unbounded partition growth (e.g. time-series rows never partitioned); very large blobs/collections in one partition; batch writes inflating partition size.
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
- Write to %s.%s partition %s: %s (WriteWarningsSnapshot.write
- <warnings msg> with <loggableTokens> (client warning; msg fr
- <warnings msg> with <loggableTokens> (client warning; msg fr
- You must use conditional updates for serializable writes
- FSWriteError
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/80ce4aa48ab81fd2.
Report an issue: GitHub.