Skip to content

When decommission is attempted again, clear any existing transferred_ranges to force re-streaming and avoid consistency violation - #5003

Open
Jollyplum wants to merge 1 commit into
apache:cassandra-4.0from
Jollyplum:mbyrd/CASSANDRA-16290/cassandra-4.0
Open

When decommission is attempted again, clear any existing transferred_ranges to force re-streaming and avoid consistency violation#5003
Jollyplum wants to merge 1 commit into
apache:cassandra-4.0from
Jollyplum:mbyrd/CASSANDRA-16290/cassandra-4.0

Conversation

@Jollyplum

Copy link
Copy Markdown
Contributor

Patch by Matt Byrd; reviewed by Caleb Rackliffe and Sam Tunnicliffe for CASSANDRA-16290

@Jollyplum
Jollyplum force-pushed the mbyrd/CASSANDRA-16290/cassandra-4.0 branch from 4fc35c5 to d07e94f Compare August 6, 2026 21:35
PendingRangeCalculatorService.instance.blockUntilFinished();

// This check needs to happen above startLeaving
boolean resumingInFlightDecommission = tokenMetadata.isLeaving(FBUtilities.getBroadcastAddressAndPort())

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why don't you just check operationMode == Mode.LEAVING ?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, so on 4.0/4.1 this is redundant the guards above guarantee we're in one of NORMAL/LEAVING.
on 5.0 however we have DECOMMISSION_FAILED which is likely a common decommission resume scenario.

The problem then becomes:

  1. decommission streams some ranges, fails late → transferred_ranges populated
  2. restart to abort → mode NORMAL, pending ranges gone, transferred_ranges rows still on disk
  3. nodetool decommission → fail due to not enough live nodes → DECOMMISSION_FAILED and crucially since we failed early enough, isLeaving == false
  4. Then nodetool decommission --force → guard true (mode ≠ NORMAL) → reset skipped, stale rows honoured → CASSANDRA-16290 data loss

I wanted to keep the patch as close as possibly between 4.0/4.1/5.0, though there are plenty of test quirks and other deltas.
We could though simplify the 4.0 and 4.1 variants if desired.
Or maybe a more succinct comment expounding a bit more on the purpose of tokenMetadata.isLeaving on 5.0 and stating here for symmetry on 4.0/4.1

@Jollyplum
Jollyplum force-pushed the mbyrd/CASSANDRA-16290/cassandra-4.0 branch from d07e94f to f08b8b5 Compare August 7, 2026 15:39
…ranges to force re-streaming and avoid consistency violation

Patch by Matt Byrd; reviewed by Caleb Rackliffe and Sam Tunnicliffe for CASSANDRA-16290
@Jollyplum
Jollyplum force-pushed the mbyrd/CASSANDRA-16290/cassandra-4.0 branch from f08b8b5 to 84598f3 Compare August 7, 2026 23:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants