Page History

...

{
  "apiKey": 18,
  "type": "response",
  "name": "ApiVersionsResponse",
  // Version 1 adds throttle time to the response.
  // Starting in version 2, on quota violation, brokers send out responses before throttling.
  // Version 3 is the same as version 2
  //
  // Starting from Apache Kafka 2.4, ApiKeys field is populated with the supported versions of
  // the ApiVersionsRequest when an UNSUPPORTED_VERSION error is returned.
  "validVersions": "0-3",
  "flexibleVersions": "none",
  "fields": [
    { "name": "ErrorCode", "type": "int16", "versions": "0+",
      "about": "The top-level error code." },
    { "name": "ApiKeys", "type": "[]ApiVersionsResponseKey", "versions": "0+",
      "about": "The APIs supported by the broker.", "fields": [
      { "name": "Index", "type": "int16", "versions": "0+", "mapKey": true,
        "about": "The API index." },
      { "name": "MinVersion", "type": "int16", "versions": "0+",
        "about": "The minimum supported version, inclusive." },
      { "name": "MaxVersion", "type": "int16", "versions": "0+",
        "about": "The maximum supported version, inclusive." }
    ]},
    { "name": "ThrottleTimeMs", "type": "int32", "versions": "1+", "ignorable": true,
      "about": "The duration in milliseconds for which the request was throttled due to a quota violation, or zero if the request did not violate any quota." }
  ]
}

Errors

Errors.INVALID_REQUEST is added.

...

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

1. When an unknown unsupported version of the ApiVersionsRequest is received by the broker, it fails back to ApiVersionsRequest v0 and sends back an ApiVersionsResponse v0 with the UNSUPPORTED_VERSION error (as today) but the broker also populates the api_versions field with the supported version of the ApiVersionsRequest.
2. When the client receives a response, it tries to deserialise it with the version it expects. If the parsing failsan unsupported version fo the ApiVersionResponse, it fails back to version 0 (as today). As version 0 of contains both the ApiVersionsResponse ErrorCode and checks the ErrorCode. If an UNSUPPORTED_VERSION error is received, the client gets the supported version provided in the ApiKeys field or default to version 0 if the ApiKeys field is emptyApiKeys fields, the client checks the error and, in case of an UNSUPPORTED_VERSION error, it checks the ApiKeys to get the supported versions or default to versions 0 if not present.

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.  

...

ApiVersions Request/Response Handling

As mentioned earlier, when the client receives a response, it tries to deserialise it with the version it expects. If the parsing failsan unsupported version fo the ApiVersionResponse, it fails back to version 0 (as today). As version 0 of contains both the ApiVersionsResponseErrorCode and checks the ErrorCode. If an UNSUPPORTED_VERSION error is received, the client gets the supported version provided in the ApiKeys field or default to version 0 if the ApiKeys field is empty. ThenApiKeys fields, the client checks the error and, in case of an UNSUPPORTED_VERSION error, it checks the ApiKeys to get the supported versions or default to versions 0 if not present. Then, it restarts the process with this version.I have 

When the client receives an INVALID_REQUEST error, it will error out and close the connection.

...