apache
KAFKA-17011: Fix a bug preventing features from supporting v0
As part of KIP-584, brokers expose a range of supported versions for each feature. For example, metadata.version might be supported from 1 to 21. (Note that feature level ranges are always inclusive, so this would include both level 1 and 21.)
These supported ranges are supposed to be able to include 0. For example, it should be possible for a broker to support a kraft.version between 0 and 1. However, in older software versions, there is an assertion in org.apache.kafka.common.feature.SupportedVersionRange that prevents this. This causes problems when the older software attempts to deserialize an ApiVersionsResponse containing such a range.
In order to resolve this dilemma, this PR bumps the version of ApiVersionsRequest from 3 to 4. Clients which send v4 promise to be able to handle ranges including 0. Clients which send v3 will not be exposed to these ranges -- the feature will simply be omitted from the response. This work is part of KIP-1022.
Did we check the kraft upgrade system tests? I can kick off a job. Looks like there may also be some issue with the build.
It seems simpler to just pass the ApiVersionsResponse version as a parameter to the Supplier (hence making it a Function, I guess)
Updated.
Let's take a look at testUnsupportedApiVersionsRequestWithVersionProvidedByTheBroker
It looks like the test was checking the ApiVersionsRequest header version against 3. So it needed to be updated to 4
https://github.com/apache/kafka/pull/16183 will wait for this PR in order to not break tests.
Looks like there are still quite a few failures for ApiVersionsRequestTest and BrokerFeaturesTest
The context here is that we’re adding kraft.version in 3.9. But not in this PR. I did add kraft.version to supportedFeatures, simply so that I could verify that the RPC results looked like what I wanted. This will cause no compatibility problems since there is no way to set kraft.version yet.