[CASSANDRA-15938] Fix support for adding UDT fields to clustering keys

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 2.2.19, 3.0.23, 3.11.9, 4.0-beta3, 4.0
• Component/s: Feature/UDT
• Bug Category: Correctness - Unrecoverable Corruption / Loss
• Severity: Critical
• Complexity: Challenging
• Discovered By: User Report
• Platform: All
• Since Version: 2.2.18

Source Control Link

https://github.com/apache/cassandra/commit/2f0eb6f799f32c6f01d1f8384d48910c34ff6a98

Test and Documentation Plan

Tests attached.

• Assignee: Alex Petrov
• Reporter: Alex Petrov

Authors

Alex Petrov

Reviewers

Caleb Rackliffe

• Created: 13/Jul/20 16:04
• Updated: 11/Jul/24 14:54
• Resolved: 22/Sep/20 09:40

Description

Adding UDT fields to clustering keys is broken in all versions, however slightly differently.

In 4.0, there will be a brief moment while schema changes are propagated during which we won’t be able to decode and compare byte sequences. Unfortunately, it is unclear what we should do in such cases, since we can’t just come up with a comparator, and we can’t ignore non-null trailing values, since this will lead to cases where compare for tuples `a;1` and `a;2` would return 0, effectively making them equal, and we don’t know how to compare unknown trailing values. Probably we should reject such query since we can’t sort correctly, but we should make the error message more descriptive than just "Index 1 out of bounds for length 1”. The only problem is that we get this exception only on flush right now, so data already propagates to the node by that time.

In 3.0, the problem is a bit worse than that, since in 3.0 we do not ignore trailing nulls, so some of the values, written before `ALTER TYPE .. ADD` become inaccessible. Both old values, and the new ones should always be accessible.

Issue Links

• is related to: CASSANDRA-19764 Corruption can occur while a field is being added to UDT clustering key