The operation to create a topic has a response schema which doesn't really match the underlying behaviour of Kafka particularly well. The response contains the replication_factor and partitions_count which are sometimes not possible to establish depending on authorization. Prior to this PR, in the case where the principal creating the topic has CREATE authority but not DESCRIBE_CONFIGS, the POST /v3/clusters/{}/topics request fails with {"error_code":40301,"message":"Topic authorization failed."} even when the topic is created successfully. The authorization failure is actually to access the replication factor, which comes back in the CreateTopicsResponse in the Kafka protocol, provided that the principal has DESCRIBE_CONFIGS authority. If principal does not have authority, the CreateTopicsResponse actually contains an inner error code, and that's translated into an exception which is thrown when the replication factor is accessed in the result.
This PR returns the replication_factor and partitions_count from the CreateTopicsResponse if present. If however, they are not present because of the authorization failure, the code does its best to return the values based on the request parameters. For example, if the request says replication_factor:2 then the response contains that also, even if the authorization failure occurred. In some cases, the request doesn't provide enough information to return the values in which case 0 is returned.
It would be better if the response schema didn't require these fields because the information is not always available. However, that would be an incompatible change in the API.
msn-tldr
commented
1 year ago
The operation to create a topic has a response schema which doesn't really match the underlying behaviour of Kafka particularly well. The response contains the
replication_factorandpartitions_countwhich are sometimes not possible to establish depending on authorization. Prior to this PR, in the case where the principal creating the topic has CREATE authority but not DESCRIBE_CONFIGS, thePOST /v3/clusters/{}/topicsrequest fails with{"error_code":40301,"message":"Topic authorization failed."}even when the topic is created successfully. The authorization failure is actually to access the replication factor, which comes back in the CreateTopicsResponse in the Kafka protocol, provided that the principal has DESCRIBE_CONFIGS authority. If principal does not have authority, the CreateTopicsResponse actually contains an inner error code, and that's translated into an exception which is thrown when the replication factor is accessed in the result.This PR returns the
replication_factorandpartitions_countfrom the CreateTopicsResponse if present. If however, they are not present because of the authorization failure, the code does its best to return the values based on the request parameters. For example, if the request saysreplication_factor:2then the response contains that also, even if the authorization failure occurred. In some cases, the request doesn't provide enough information to return the values in which case 0 is returned.It would be better if the response schema didn't require these fields because the information is not always available. However, that would be an incompatible change in the API.