Cassandra 4.0.8 refuses cleanup while ranges are pending
Cassandra adds a guard against running cleanup during membership changes. The reported failure shows why current ownership alone is insufficient while data is moving.
A cleanup operation can remove data that a node needs to keep when the cluster is changing ownership. CASSANDRA-16418 reports that running cleanup during decommission silently deleted streamed data. The operation treated that data as redundant because it did not account for pending ranges.
Cassandra 4.0.8, released on February 14, adds a safeguard that fails cleanup when the node has pending ranges. The release changelog lists this correction among the maintenance work for the 4.0 line. The important behavior is refusal to perform a normally useful operation when its ownership assumptions are incomplete.
I find Cassandra valuable when the application needs distributed availability and active-active operation. That benefit comes with membership transitions that deserve explicit rules. This patch is useful because it puts one such rule in the implementation instead of requiring every operator to infer it from the topology protocol.
Ownership changes take time
The 4.0.8 topology documentation explains bootstrapping as a node joining the cluster and becoming responsible for token ranges. Once tokens have been allocated, the joining node streams data from existing replicas for the ranges it will own.
Removing a node also changes range responsibility. Decommission streams from the leaving node, while removing a dead node streams from surviving replicas. During either process, the system must represent a transition between the previous ownership and the resulting ownership. The data movement is part of making the new arrangement usable.
Cleanup removes data that is no longer necessary on a node. The documentation recommends it after moving a node to remove unnecessary data. That recommendation describes a position after a topology operation, rather than permission to treat ownership as stable throughout every intermediate stage.
The issue report exposes the consequence of confusing those stages. Data had arrived through streaming, but cleanup classified it using an ownership view that omitted pending responsibility. Removing it changed subsequent query results even though the operator expected cleanup to preserve those results.
The report's author suspected a symmetric problem during bootstrap but explicitly said it had not been verified. That distinction should remain in an account of the defect. The demonstrated event involved decommission. The safeguard covers the implementation's pending-range condition more generally.
The guard lives before table cleanup
The StorageService implementation in 4.0.8 checks pending ranges for the requested keyspace and the local broadcast address. If that collection is nonempty, it throws an exception stating that cleanup is unsafe because the node is involved in membership changes.
This check occurs before the method iterates over the selected tables and invokes their cleanup operations. The operation consequently refuses the request at the service level rather than starting table cleanup and discovering the membership problem afterward. That placement keeps the unsafe assumption out of the work it governs.
The condition is also more precise than saying that cleanup is forbidden whenever any unrelated activity exists in the cluster. The code checks pending ranges for this node and keyspace. An operational description should preserve that scope instead of replacing it with an unsupported global lock model.
This is a useful example of a precondition for maintenance. The desired result is not merely completion of a command. Completion is acceptable only if the system state supports the command's interpretation of which data is redundant.
A refused command carries information
An operator encountering the new failure has evidence that the requested cleanup does not meet that precondition. Retrying immediately does not alter the membership state. The relevant dependency is completion or resolution of the range transition that makes the node's pending ranges nonempty.
The patch does not claim to repair every topology problem or eliminate the need to inspect membership progress. It prevents one destructive interaction between cleanup and pending ownership. That bounded claim is sufficient to explain why a maintenance update can matter to data correctness.
My preference is for maintenance interfaces to reject an operation when the implementation can identify an invalid state. A documented sequence still matters, but the software has the information needed to prevent this particular mistake before removing data.
Other fixes improve operational evidence
The release also repairs the full-query-log dump tool. Its changelog lists a correction for separating entries and a null-value failure. These are distinct from the pending-range safeguard, but both affect an operator's ability to understand database activity.
Another change adds warnings for aggregation queries without a key or over multiple keys. The release does not claim to prohibit those queries. It adds diagnostic evidence about a query form that can be operationally consequential.
Taken together, these changes keep the maintenance release focused on concrete behavior. Cleanup now checks whether pending ownership makes its removal decision unsafe. Logging tools and warnings provide more usable information about other operations. The key data-preservation change is the pending-range check before cleanup reaches the selected tables.