Page History

...

The client does not know which ApiVersions versions the broker supports as the ApiVersions is used for this purpose. Today, the client sends an ApiVersionsRequest with the latest schema it is aware of. The broker handles it with the correct version if it knows it or sends back an ApiVersionsResponse v0 with an UNSUPPORTED_VERSION error to the client if it doesn't. When the client receives such error, it retries the whole process with the ApiVersionsRequest v0. It means that any fields added after version 0 but before the highest version supported by the broker won't be provided by the client. In our case, we would like to ensure that any future version of the ApiVersionsRequest won't impact the availability of the ClientSoftwareName and the ClientSoftwareVersion. 

To circumvent this, we propose to provide the supported enhance the fail back mechanism as follow:

1. When a version of the ApiVersionsRequest

...

1. is received by the broker, it continues to send back an ApiVersionsResponse (version 0) with the UNSUPPORTED_VERSION error but also populate the api_versions field to inform the consumer about the supported versions of the ApiVersionsRequest.
2. When the client receives an UNSUPPORTED_VERSION error, it leverage the information provided in the api_versions field to fail back to the higher version supported by the broker

...

1. or default to version 0 if api_versions is empty.

At the moment, the ApiVersionsRequest is handled in two different places in the broker: 1) in the SaslServerAuthenticator (when used); and 2) in the KafkaApis. Both places will be updated to ensure that all clients work. We have decided to not refactor the handling of the ApiVersionsRequest for now and to leave it for further improvements.  

...