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

Reply via email to