Hi Nicole, Thanks for the KIP! I have only two comments:
DJ01: What's the reasoning for not including groups with only pending offsets? DJ02: I wonder if we should simplify the "State of the group at the read snapshot" table. For instance, "is visible in the snapshot" is an implementation detail. We should rather say that the condition is applied to the committed state and simplify the table. Best, David On Mon, Oct 26, 2026 at 11:49 PM Nicole Du <[email protected]> wrote: > > Hi all, > > I'd like to start a discussion on KIP-1388, which proposes adding a > request-side filter to the ListGroups API to allow Admin.listGroups to > return only groups with at least one committed offset. > > Tools that replicate consumer group offsets across clusters, such as > MirrorMaker 2 and the group offset sync in KIP-1279, typically list all > groups before fetching their offsets. In large deployments, many groups may > have active members but no committed offsets, resulting in unnecessary > OffsetFetch requests and additional load on group coordinators. > > This KIP proposes filtering these groups on the server side by introducing > a new request field in ListGroups v6 and exposing it through > ListGroupsOptions.requireCommittedOffsets(boolean). > > KIP: > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1388%3A+Add+a+committed-offsets+filter+to+ListGroups > > JIRA: https://issues.apache.org/jira/browse/KAFKA-21366 > > I'd appreciate any feedback or suggestions. > > Thanks, > Nicole
