I could see a situation where you pass a status to Kafka for a specific Consumer Group. That status could be resetLatest or resetEarliest and Kafka handles the signal similar to a rebalance but sets the offset based on the earliest/latest. I think anything more, like passing a map of partitions and offsets, could over complicate things.
-- Andrew On Tue, Nov 11, 2025, 6:59 AM Levani Kokhreidze <[email protected]> wrote: > Hi all, > > > > I'd like to get some feedback from the community on the following idea. > > Currently, to safely perform a consumer group offset reset, the consumer > group must be inactive. In practice, for a production service, this means > the entire service must be stopped to perform the reset. Depending on the > service's criticality, this isn't always possible. > > The alternative is to build custom tooling for our Kafka clients that > allows them to be shut down on request. However, developing this > client-side tooling is expensive, and that cost multiplies when you need to > support multiple programming languages. > > I understand why resetting offsets on an active consumer group is > problematic. This leads me to wonder: what is the community's opinion on > developing more advanced broker-side management for the consumer groups? > > In short, what if we could use the AdminClient to mark a specific consumer > group as "inactive"? This state would then enable us to perform an offset > reset safely, without ever needing to make changes or take actions on the > client side. > > I appreciate that "marking a consumer group as inactive" is an abstract > term, and there are many nuances and details to think through. At this > point, I'm just looking for super-early feedback from more experienced > Kafka developers on whether this general idea makes sense. > > If it does, my team and I would be very interested in helping to deliver > this feature. We can start working on a KIP to share with the community. We > would also appreciate any early pointers on how to approach this if you > think it's a viable idea. > > > > Thanks, > > Levani
