Hi Sunmin, Thanks for the KIP!
I agree with the fundamental issue that you describe in the KIP -- there is no way to see the effective value today because the DescribeConfigs API returns the stored value -- but I disagree with the proposed approach. Passing the configs to the clients via all those APIs does not seem right to me. Each API should stay focused on its main responsibility, and distributing configs is not the job of the heartbeat or the share fetch APIs. The configs that they return today, like the heartbeat interval, are there because the client uses them. This approach also adds a lot of complexity, and I don't think it is worth it just to log the values. Finally, it lets any member read the group configs without the DESCRIBE_CONFIGS permission, which is the one that controls this. We should definitely look into whether we could improve the DescribeConfigs API to return the effective values though. I am happy to help on that front. If we really want to log them on the client, we should just use the DescribeConfigs API to get them. Another question is whether we really need to log all those configs on the client side. I am not sure that I fully understand the benefit of it. The group configs do not change that often and they are easily accessible via the command line tool and the admin client. The effective value also only differs from the stored one when an administrator changes the broker bounds so that they exclude an existing override, which is uncommon in practice. Assuming that we fix the DescribeConfigs API, it seems sufficient to troubleshoot issues. Do you have concrete use cases where it would be helpful? Best, David On Wed, Oct 28, 2026 at 3:08 AM 이선민 <[email protected]> wrote: > > Hi all, > > I would like to start a discussion on KIP-1389: > https://cwiki.apache.org/confluence/spaces/KAFKA/pages/462815689/KIP-1389+Surface+effective+group+configurations+to+clients > > JIRA: https://issues.apache.org/jira/browse/KAFKA-20848 > > With the consumer group protocol (KIP-848), share groups (KIP-932) and the > Streams rebalance protocol (KIP-1071), settings such as the session timeout > are group configurations owned by the broker, and a stored group override can > be clamped to the broker's bounds (KIP-1240). Today the client cannot see the > values in effect, nor that an override was not applied. > > This KIP adds an optional list of effective group configurations to the > ConsumerGroupHeartbeat, ShareGroupHeartbeat, StreamsGroupHeartbeat, ShareFetch > and ShareAcknowledge responses, each reported by the broker that applies the > configuration. The list is sent as tagged fields and only when its content > changes, using a content token echoed by the client. Clients log the values on > first receipt and on change, and warn when a stored override differs from the > value in effect. Client behavior does not change. > > On the release: KIP-1313 introduces a new version of every RPC in 4.5. If this > KIP lands in the same release, I would like to add the fields to those > versions in coordination with KAFKA-20925. Andrew, I would appreciate your > view > on whether that works. > > Feedback is welcome. > > Thanks, > Sunmin Lee
