Hi Kirk, Thanks for the KIP. Inevitably, I have some comments. AS1: I see a few mysterious mentions of "profile". I suppose that these are evidence of a concept which did not eventually see the light of day in the KIP.
AS2: It seems that the default configurations pushed for a share consumer are incorrect (because some of them are group configs not client configs). I suggest: * client.id * group.id * share.acknowledgement.mode * share.acquire.mode * max.poll.records * max.poll.interval.ms * fetch.min.bytes * fetch.max.wait.ms AS3: Is there any reason why you need to send the configuration type information to the broker? I wonder if it would be simpler just to leave everything as strings. I see that you've got a enum for ClientConfigType which is awfully similar to Config.Type, and you're going to end up mapping between these enums. AS4: ClientConfigUnknownProfileException has a couple of problems. We tend to use Unknown at the start of the error codes and exception class names, not the middle. Profile is not a thing. I suggest it should be UnknownClientConfigSomethingException, but I am not qualified to say what the Something is. AS5: You should include a list of the exceptions and error codes you are introducing to the protocol. I've seen a few new exceptions and they generally have error codes which correspond 1:1. * ClientConfigUnknownProfileException - Should this just be InvalidConfigurationException (exists) which maps to INVALID_CONFIG error code? * ClientConfigTooLargeException - I would expect this to map to the CLIENT_CONFIG_TOO_LARGE error code (new) * ClientConfigPolicyException - See AS4. Policy exceptions are usually PolicyViolationException, but this policy doesn't validate, it just processes. AS6: You've tended to use Config (singular) not Configs (plural). However, in the configurations for the configurations, you've used plural, such as client.configs.policy.class.name. I would err on the side of consistency. AS7: We are going to have to resolve the relationship between this KIP and KIP-1313. The latter introduces client instance ID on all RPCs, and will simplify your KIP if it is accepted first. AS8: Please confirm whether there are any timing considerations between PushConfigs and GetTelemetrySubscriptions/PushTelemetry RPCs. I suppose that a client could overlap these RPCs, or even send them to different randomly selected brokers, as part of its initial connection setup. AS9: Please add some broker metrics for this new feature. I suggest looking at KIP-714 for inspiration. AS10: Why does the client block while the config handshake is being performed? The handshake is not validating the configurations and the client doesn't throw an exception even if the PushConfigs response contains an error code. Doesn't this unnecessarily slow down the initial connection, and that's arguably too long with Kafka clients already. AS11: Which are the default configurations sent for the Apache Kafka Java admin client? Thanks, Andrew On 2026/04/23 17:59:11 Kirk True wrote: > Hi all, > > I would like to start a discussion on KIP-1324: Support client configuration > observability: > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1324%3A+Support+client+configuration+observability > > Thanks, > Kirk >
