[CASSANDRA-19764] Corruption can occur while a field is being added to UDT clustering key

• Type: Bug
• Status: Triage Needed
• Priority: Normal
• Resolution: Unresolved
• Component/s: Feature/UDT
• Platform: All
• Assignee: Unassigned
• Reporter: Branimir Lambov
• Created: 11/Jul/24 14:52
• Updated: 12/Jul/24 13:20

Description

CASSANDRA-15938 made some improvements in how unknown components in UDTs are treated. Unfortunately this can cause corruption as soon as more than one value is inserted for a partition.

The problem can be easily shown by modifying the FrozenUDTTest.testDivergentSchema test to insert two entries in the wrong order:

cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i) VALUES (?, " + json(1, 2) + ", ? )", ConsistencyLevel.ALL,
1, 2);
cluster.coordinator(1).execute("insert into " + KEYSPACE + ".x (id, ck, i) VALUES (?, " + json(1, 1) + ", ? )", ConsistencyLevel.ALL,
1, 1);

after which we can get corrupted sstable state, shown as a

java.lang.AssertionError: Lower bound [SSTABLE_LOWER_BOUND(1) ]is bigger than first returned value [Row: ck=1 | i=2]

exception, or results like [[1],[2],[2],[1]] or [[2],[1],[2]] for select i from x WHERE id = 1 depending on which node we use as coordinator.

Because we don't know the type of new fields and cannot properly order entries, we need to outright reject UDT keys that are not compatible with a replica's schema.

Issue Links

• relates to: CASSANDRA-15938 Fix support for adding UDT fields to clustering keys