KAFKA-18269: Remove deprecated protocol APIs support (KIP-896, KIP-724) for 4.0 #18291
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.
Included in this change:
Errors.UNSUPPORTED_COMPRESSION_TYPE
on the fetch path[1].TopicConfig. MESSAGE_DOWNCONVERSION_ENABLE_CONFIG
and made the relevantconfigs (
message.downconversion.enable
andlog.message.downcoversion.enable
) no-ops sincedown-conversion is no longer supported. It was an oversight not to deprecate this via KIP-724.
shouldRetainsBufferReference
to handle null request schemas for a given version.Testing:
Note that this also completes part of KIP-724: produce v2 and lower as well as fetch v3 and lower are no longer supported.
Future PRs will remove conditional code that is no longer needed (some of that has been done in KafkaApis,
but only what was required due to the schema changes). We can probably do that in master only as it does
not change behavior.
Note that I did not touch
ignorable
fields even though some of them could have beenchanged. The reasoning is that this could result in incompatible changes for clients
that use new protocol versions without setting such fields if we don't manually
validate their presence. I will file a JIRA ticket to look into this carefully for each
case (i.e. if we do validate their presence for the appropriate versions, we can
set them to ignorable=false in the json file).
[1] We would return this error if a fetch < v10 was used and the compression topic config was set
to zstd, but we would not do the same for the case where zstd was compressed at the producer
level (the most common case). Since there is no efficient way to do the check for the common
case, I made it consistent for both by having no checks.
[2]
org.apache.kafka.common.errors.UnsupportedVersionException: The broker is too new to support JOIN_GROUP version 1
[3]
METADATA|rdkafka#producer-1| [thrd:main]: localhost:9092/bootstrap: Metadata request failed: connected: Local: Required feature not supported by broker (0ms): Permanent
[4]
METADATA|rdkafka#consumer-1| [thrd:main]: localhost:9092/bootstrap: Metadata request failed: connected: Local: Required feature not supported by broker (0ms): Permanent
[5]
ERROR: Topic test-topic [0] error: Failed to query logical offset END: Local: Required feature not supported by broker
Cherry-pick was clean, minor changes required to
LogOffsetTest
due to a commit that is inmaster
, but not4.0
.