fix(protocol): handle ElectLeaders V1 non-flexible headers#3478
Open
fix(protocol): handle ElectLeaders V1 non-flexible headers#3478
Conversation
Signed-off-by: DCjanus <DCjanus@dcjanus.com>
Signed-off-by: DCjanus <DCjanus@dcjanus.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
ElectLeadersrequest/response version 1 must use the non-flexible wire format.That path was fixed once in #3312, but a later refactor left the
ElectLeadersheader version selection inconsistent with the protocol version again. As a result, a client configured forV2_3_0_0can fail to decodeElectLeadersV1 responses from newer brokers with:kafka: insufficient data to decode packet, more bytes expectedWhat
ElectLeadersV1 non-flexible pathElectLeadersrequest/response header versions from the actual protocol version instead of treating V1 as flexibleTesting
This PR contains two commits. The first commit only adds a functional test and is expected to fail. The second commit only contains the protocol fix and is expected to make CI pass.
Before opening this PR, I created a draft PR in my fork to run CI and verify that the test was actually effective.