Hi David, Thanks for taking a look and for the suggestions!
For DJ01: My reasoning was to keep the predicate focused on offsets that have already been committed. Pending transactional offsets may still be aborted, so they do not count on their own. A group with an existing committed offset still matches even if it also has pending offsets. I’ve clarified this in the KIP. One trade-off is that a pending-only group that commits after the listing is evaluated needs a subsequent listing to be discovered. I’d appreciate your thoughts on whether including pending-only groups would be more useful for callers. For DJ02: That makes sense. I’ve replaced the snapshot-specific wording with a definition based on the coordinator’s committed state and simplified the table to three cases: at least one committed offset, pending offsets only, and neither. A separate sentence clarifies that offsets eligible for expiration continue to count until their deletion takes effect. I’ve also made two small updates to the existing test plan: explicitly covering pending offsets through transaction commit and abort, and describing the visibility test in terms of committed state. Best, Nicole On Wed, Oct 28, 2026 at 7:51 AM David Jacot <[email protected]> wrote: > 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 >
