You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Nivy Kani <ni...@apple.com> on 2026/07/27 23:58:37 UTC
[DISCUSS] Backport truncateBlocking bug fix to 4.0?
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
Re: [DISCUSS] Backport truncateBlocking bug fix to 4.0?
Posted by Ekaterina Dimitrova <e....@gmail.com>.
Hi Nivy,
Without looking into the test and PRs, general response, I’d say a data
loss bug absolutely needs to be fixed in all existing versions that the
community maintains at the moment (I believe this includes 4.0 at the
moment).
Best regards,
Ekaterina
On Tue, 28 Jul 2026 at 12:28, Nivy Kani <ni...@apple.com> 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
>
Re: [DISCUSS] Backport truncateBlocking bug fix to 4.0?
Posted by "C. Scott Andreas" <sc...@paradoxica.net>.
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 <ni...@apple.com> 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