MINOR: fix compatibility-breaking bug in RequestHeader#7479
Merged
cmccabe merged 3 commits intoapache:trunkfrom Oct 10, 2019
Merged
MINOR: fix compatibility-breaking bug in RequestHeader#7479cmccabe merged 3 commits intoapache:trunkfrom
cmccabe merged 3 commits intoapache:trunkfrom
Conversation
Fix a compatibility break in trunk introduced by the work on KIP-511 and KIP-482. Older brokers must be able to read the first part of any version of ApiVersionsRequest that they get sent without encountering an error. Therefore, the first part of any new version of the RequestHeader must match the first part in the old header version used alongside the original ApiVersionsRequest.
cmccabe
changed the title
hachikuji
approved these changes
Oct 9, 2019
Contributor
hachikuji
left a comment
hachikuji
left a comment
There was a problem hiding this comment.
LGTM. I think the comment could be improved a little bit, but the change makes sense.
Member
|
There is another subtle issue: https://github.com/apache/kafka/pull/7372/files#r333493561 Could we address that in this PR too? |
Member
|
|
Contributor
Author
|
I pushed a fix for the unit test. The null / empty string issue seems more subtle, so let's discuss that in a follow-on. |
asfgit
pushed a commit
that referenced
this pull request
Oct 10, 2019
Reviewers: David Arthur <mumrah@gmail.com>, Jason Gustafson <jason@confluent.io>, Ismael Juma <ismael@juma.me.uk> (cherry picked from commit 5c4bbf9)
Closed
3 tasks
twmb
added a commit
to twmb/franz-go
that referenced
this pull request
Oct 14, 2019
Noticed a regression, asked about it, was pointed to same fix in Kafka itself: apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
May 27, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
May 31, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
May 31, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
May 31, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
Jun 1, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
Jun 1, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
Jun 2, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
graphcareful
pushed a commit
to graphcareful/redpanda
that referenced
this pull request
Jun 3, 2022
- KIP-511 mentions that api_versions_response will not encode tags within the headers to preserve backwards compatability with clients that expect the error code at a fixed position within the response. - Furthermore if the client made an api_versions_request past the max supported version, then the response is to be sent as a v0 response, this means we cannot encode the response data with flexible structures. - Fix to the same thing in kafka itself apache/kafka#7479
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
4 participants
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.
Fix a compatibility break in trunk introduced by the work on KIP-511 and KIP-482.
Older brokers must be able to read the first part of any version of ApiVersionsRequest that they get sent without encountering an error. Therefore, the first part of any new version of the RequestHeader must match the first part in the old header version used alongside the original ApiVersionsRequest.