cmccabe commented on pull request #8639: URL: https://github.com/apache/kafka/pull/8639#issuecomment-636286034
@rajinisivaram wrote: > @cmccabe found a compatibility issue with the KIP and made some changes. I think the change was to allow ConsumerGroupDescription#authorizedOperations to return null instead of throwing an exception since there wasn't an easy way to throw an exception for this case. Hmm. I think the JIRA you're thinking of is KAFKA-8158. The bug was that new client + old server was silently returning an empty set of auth operations, rather than throwing an exception OR returning null. My change was intended to fix that, not to change the behavior from exception to null (or vice versa). @jsancio wrote: > I don't know @rajinisivaram. Based on what the Admin client exposes there is no way for the client/KSQL to determine if the server version supports this feature, no? Well, the client can handle the `UnsupportedVersionException and stop requesting the authorized operations. Anyway, if you folks feel strongly that it should silently return null rather than throwing a UVE, I'm OK with this change. To be clear, the null (rather than empty) set does let the client know for sure that the authorized operations request was not supported. I suppose the fact that we did return null for this in 2.3 and 2.4 rather than a UVE is a strong argument for doing it that way in 2.6 and beyond. Let's just update the KIP and also bump the KIP thread as well. I agree with @ijuma that we should also change the compatibility tests for this in ducktape. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
