[CASSANDRA-15193] Add ability to cap max negotiable protocol version

• Type: Bug
• Status: Resolved
• Priority: Normal
• Resolution: Fixed
• Fix Version/s: 3.0.19, 3.11.5, 4.0-alpha2, 4.0
• Component/s: Messaging/Client
• Bug Category: Availability - Response Crash
• Severity: Normal
• Complexity: Normal
• Discovered By: Unit Test
• Platform: All
• Since Version: 3.0.0

Source Control Link

https://github.com/apache/cassandra/commit/0388d89e29393d0b1f50baa24848bc8cb0a7c9a3

Test and Documentation Plan

Expanded unit test coverage

• Assignee: Sam Tunnicliffe
• Reporter: Sam Tunnicliffe

Authors

Sam Tunnicliffe

Reviewers

Aleksey Yeschenko, Alex Petrov

• Created: 02/Jul/19 09:59
• Updated: 15/May/20 08:54
• Resolved: 08/Oct/19 19:31

Description

3.0 and native protocol V4 introduced a change to how PagingState is serialized. Unfortunately that can break requests during upgrades: since paging states are opaque, it's possible for a client to receive a paging state encoded as V3 on a 2.1 node, and then send it to a 3.0 node on a V4 session. The version of the current session will be used to deserialize the paging state, instead of the actual version used to serialize it, and the request will fail.

CASSANDRA-15176 solves half of this problem by enabling 3.0 nodes to serialize mis-versioned PagingStates. To address the other side of the issue, 2.1 nodes receiving V4 PagingStates, we can introduce a property to cap the max native protocol version that the 3.0 nodes will negotiate with clients. If we cap this to V3 during upgrades, no V4 connections will be established and so no incompatible PagingStates will be sent to clients.