Hi Aditya, Thanks for your reply. Sorry for the delay. AK1: One of the advantages of the file is that it's possible to export from one group type and import into another. You can also export offsets for multiple groups, and this changes the file format (4 columns instead of 3). Sadly, this is all existing behaviour that I only learnt by trial and error. Personally, I think that export-import is a relatively infrequent operation, and the KIP makes enough of a step forward. I wonder if you could elaborate a bit more on your idea. Feel free to push back if you disagree.
AK2: The KIP does not mention this and I wasn't quite sure where to add it. You are correct. Should we improve the javadoc for the admin client? AK3: Yes, Admin is better. KIP updated. AK4: The DescribeGroupsGeneric RPC is intended as a way of getting a minimal set of group information for groups of any group types. It is used in Admin.describeGroups and this would be the initial Admin call from bin/kafka-XXXX-groups.sh when exporting or resetting offsets. It gives a way to check the group type and existence unambiguously. By contrast, if you use Admin.describeXXXGroups() for an existing group ID of the wrong type, the error code is GROUP_ID_NOT_FOUND. AK4.1: I didn't include the members intentionally. This RPC is agnostic to group type. I think the common subset of group attributes is group ID, group type, group state and coordinator. If you dig deeper, you find that the group types differ. For example, assignments in consumer groups and share groups are partitions, while in streams groups they are tasks. I expect we'll add connect groups one day, and until we have the KIP, I wouldn't want to assume the details of membership. AK4.2: This is following existing convention I'm afraid and I want to be consistent. If the broker does not send back a list of ACL operations, then this will be null. This is different than an empty set which means "you are not authorized", as opposed to "you don't know anything about authorized operations". Thanks, Andrew On 2026/07/27 05:45:27 Aditya Kousik wrote: > A small correction. > > I meant to add a statement before the numbered comments. > > “Since the KIP motivation revolves around usability of the script, would you > be willing to consider the following:” > > Also, typo on AK2. “…As long as there aren’t any active members in the group > subscription”. > > -Aditya > > > On Jul 25, 2026, at 23:53, Aditya Kousik <[email protected]> wrote: > > > > Hi Andrew, > > > > Thanks for this KIP, I’ve personally faced more than one scenario where > > I’ve had to use the admin client to update the offsets. > > > > The main uses cases teams face ( and TIL about the various options the > > script offers): > > Teams migrating to a new consumer group from an existing one but don’t want > > to commit to either (or duration for newer clients) auto offset reset > > policy on the new group. > > Teams want to seek past certain offsets in partitions because they have > > poison pill messages/corrupted deserialization story and they have no > > control over the data. In this case, they actually want latest offset > > strategy but most don’t even realise that it applies to streams out of > > range and are surprised/frustrated that the property doesn’t move their > > position in the queues. (I see we can do this already in the script today) > > When I migrated our clients from 2.x directly to 4.x, out of abundance of > > caution, I wrote an hourly cron job that dumps the snapshot of > > group_id,topic,partition,offset into csv files so that if I had to revert a > > few affected partitions I can trim the csv down to those partitions and > > alter them with the admin client. > > > > AK1. A single command line with args —source-group-id —target-group-id > > —export so that the intermediate CSV file can be skipped. > > AK2. Minor: The KIP does not mention the alter/list consumer group offsets > > Admin call. alter only works as long as there are active members in the > > group subscription. I was bitten by this in the past; the documentation was > > sparse around that expectation but it does make sense. > > AK3. KIP references AdminClient but I believe this is deprecated in favour > > of just Admin which is the interface that has the methods? > > AK4. How do we leverage the describe groups RPC when using the script/admin > > client? I’m trying to imagine flows other than the export group offsets. > > AK4.1 Can we list active members/offset state in a given group in addition > > to the GroupState? This has helped identify zombie processes to hunt down. > > The broker’s view would be useful here. (related to AK2) > > AK4.2 Could we return empty set of acl operations instead of null? > > > > Best, > > Aditya > > > > > >> On 2026/06/17 06:34:11 Andrew Schofield wrote: > >> Hi, > >> I’d like to start discussion on a small KIP to improve the usability of > >> the command-line tools for resetting group offsets. When implementing > >> KIP-1323 and reviewing the PRs, it became clear that the usability of this > >> area of Kafka isn’t great. This KIP improves the usability of these tools. > >> > >> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1359%3A+Improve+usability+of+resetting+group+offsets > >> > >> Thanks, > >> Andrew > >> >
