[CASSANDRA-16721] Repaired data tracking on a read coordinator is susceptible to races between local and remote requests

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 4.0.1, 4.1-alpha1, 4.1
• Component/s: Consistency/Coordination
• Bug Category: Availability - Response Crash
• Severity: Normal
• Complexity: Normal
• Discovered By: User Report
• Platform: All
• Since Version: 4.0.0

Source Control Link

https://github.com/apache/cassandra/commit/585bc692918deea2b8c4b1098ee7e7478881f138

Test and Documentation Plan

New dtests added

• Assignee: Caleb Rackliffe
• Reporter: Sam Tunnicliffe

Authors

Caleb Rackliffe, Sam Tunnicliffe

Reviewers

Alex Petrov, Caleb Rackliffe, Sam Tunnicliffe

• Created: 07/Jun/21 18:37
• Updated: 28/Feb/24 17:13
• Resolved: 27/Aug/21 17:03

Description

At read time on a coordinator which is also a replica, the local and remote reads can race such that the remote responses are received while the local read is executing. If the remote responses are mismatching, triggering a DigestMismatchException and subsequent round of full data reads and read repair, the local runnable may find the isTrackingRepairedStatus flag flipped mid-execution. If this happens after a certain point in execution, it would mean
that the RepairedDataInfo instance in use is the singleton null object RepairedDataInfo.NULL_REPAIRED_DATA_INFO. If this happens, it can lead to an NPE when calling RepairedDataInfo::extend when the local results are iterated.

Issue Links

• relates to: CASSANDRA-14145 Detecting data resurrection during read