Nivy, thank you for reporting this issue and contributing a patch! The relevant ticket is: https://issues.apache.org/jira/browse/CASSANDRA-21527
This is a pretty surprising and scary finding. I am surprised it's gone unnoticed until now. – Scott > On Jul 28, 2026, at 9:28 AM, Nivy Kani <[email protected]> wrote: > > > Hi all, > > We noticed a bug that could cause data loss, where in rare cases, truncation > can claim to succeed despite failing. > > When a user sends a truncate request, any in-progress compactions are > cancelled, since we want to remove the data anyway. > > The problem is that truncateBlocking can’t differentiate between a successful > truncate vs skipping truncate due to failure to stop compaction (caused by > hitting the 60s timeout or higher-priority compactions), because both cases > return null. In both cases, it appears successful and logs “Truncate > complete”. > > The bug has existed since at least 4.0, which can be seen with this failing > test: > https://github.com/apache/cassandra/compare/cassandra-4.0...nivykani:cassandra:4.0-truncate?expand=1 > > A proposed fix is: https://github.com/apache/cassandra/pull/4948 > > The question is, do we want to backport this all the way to 4.0? If not, > which version should this fix be backported to? > > Best, > Nivy
