-
Notifications
You must be signed in to change notification settings - Fork 14.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
KAFKA-18646: Null records in fetch response breaks librdkafka #18726
Merged
ijuma
merged 3 commits into
apache:trunk
from
ijuma:kafka-18646-null-records-breaks-librdkafka
Jan 29, 2025
+42
−6
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removing
nullableVersions
would prevent Kafka from "reading" null records. This could potentially pose a risk. Therefore, we might consider a strategy where Kafka strictly enforces that null records are never "written" while still maintaining the ability to "read" them.In summary, I favor @mumrah's suggestion of adding a null check. Furthermore, we should include a comment explaining the rationale behind preventing Kafka from writing null records.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please elaborate on the risk - what is the exact use case where that would happen? I couldn't come up with one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Keep in mind that released versions of Kafka never return null records - if that ever happened, it would have broken librdkafka. Same for any other implementation of the Kafka protocol.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe
FetchResponse.json
should be considered part of the public interface. Consequently, modifying the "released spec" carries inherent risks. We cannot guarantee that no external implementations adhere to our specification. For instance, other server implementations might return null records, and after this PR, our 4.0 client would no longer be able to read them.that is true and it does not violate the spec, right? I mean "apache kafka can never return null even though the spec says it is valid to return null"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree, the actual spec here is that this field can never be null. As I said, there is no Kafka implementation that doesn't work with librdkafka and related clients - it constitutes 30-50% of Kafka clients in the wild.
What happened here is that the spec definition was actually incorrect - it specified the field as nullable even though it couldn't be. And that bug meant we accidentally broke a large part of the ecosystem. I don't see the benefit in not fixing the spec.
Again, let's discuss a concrete use case - you're worried that the Java consumer might break because there is an unknown Kafka broker that implements this differently?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have no evidence that there is a broker implementation that returns null records. If librdkafka and related clients constitute 30-50% of clients, it is acceptable to fix the specification.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this behavior in librdkafka has existed for a long time, and we have not seen an issue with null records prior to the recent changes, I think it is safe to say we have never returned null records.
I think fixing the protocol spec makes sense.