Hi Matthias, Thank you for the feedback. It’s an interesting idea, and I am more than happy to explore it. The idea of having a dedicated RPC for pause/resume came from the original email thread [1] when I proposed this functionality. I would be curious to hear David’s and Lucas’s thoughts on the subject as well.
Best, Levani [1] - https://lists.apache.org/thread/d45hpm86fxvc6f81svmzjo8hp8sjft5y > On 22. Jul 2026, at 00:22, Matthias J. Sax <[email protected]> wrote: > > Hello Levani, > > I am very excited about this KIP -- I fully agree on the motivation, but I > think we need to do this very differently. I am glad so see that the KIP > already mentioned "streams" groups, but for this case we should take a > potential client-side state store reset into account. -- And yes, I think we > should also include "share" groups. Building out one unified solution for all > group types will provide the best user experience. > > On a high-level, I don't think we should add pause/resume or similar RPCs as > currently proposed, but rather a new ResetOffsetsRPC, and this RPC should > encode all information the GC needs to orchestrate the reset. > > I would also not necessarily revoke any partitions, but change the existing > heartbeats responses to include information about an ongoing offset reset, > and clients would get updated accordingly to do the right thing during an > ongoing reset. We need to define what "the right thing" would be. I believe > this would be a much better end-to-end design. > > Yes, this description is high level, but I wanted to paint a direction > picture to see what everybody thinks about it. > > We will also need to figure out how we keep track of "reset progress" and > many corner cases like membership changes (and failures) during an ongoing > reset, and how to decide when a reset was completed etc. For example, there > is a corner case for Kafka Streams w/ client side state store reset, which > could lead to bad behavior: a client with local state might drop out of the > group, a reset happens afterward, and the client rejoins later. For this > case, we need to still ensure that the client would reset it's local state > correctly, even if it was not part of the group during the reset > orchestration. > > Curious to hear what you think about this direction. > > > -Matthias > > > > On 3/23/26 12:15 AM, Levani Kokhreidze wrote: >> Hi, >> Gentle bump on this KIP in case anyone else wants to share their feedback. >> Best, >> Levani >>> On 16. Mar 2026, at 08:32, Sushant Mahajan <[email protected]> wrote: >>> >>> Hi, >>> Thanks for the reply. >>> >>> On Tue, 10 Mar 2026, 02:58 Levani Kokhreidze, <[email protected]> >>> wrote: >>> >>>> Hi Sushant, >>>> >>>> Thanks for the comments. >>>> >>>> RE sm01: >>>> I haven’t researched the share groups support as I wasn’t sure if it would >>>> be even useful for the share groups to support this feature. >>>> But usefulness of this feature was mostly discussed around the new >>>> consumer group protocol and streams protocol [1]. >>>> Share groups support can be a followup KIP as well. >>>> >>>> RE sm02: >>>> For the new consumer group protocol we will be utilising the heartbeat API >>>> to update the assignment based on the paused partitions state. >>>> As for heartbeat API for the classic group, I do not think it gives any >>>> hint around target assignment, that will be still up to the client side >>>> assignor to handle. >>>> Since classic groups will eventually be deprecated, I believe it makes >>>> more sense to focus on the new consumer group protocol. >>>> >>>> I hope this answers your questions. >>>> >>>> Thanks, >>>> Levani >>>> >>>> [1] - https://lists.apache.org/thread/d45hpm86fxvc6f81svmzjo8hp8sjft5y >>>> >>>>> On 6. Mar 2026, at 13:38, Sushant Mahajan <[email protected]> wrote: >>>>> >>>>> Hi Levani, >>>>> Thanks for the KIP. >>>>> >>>>> sm01: Is there any reason for not including share groups as supported >>>> group >>>>> types? >>>>> >>>>> sm02: Can heartbeat API be leveraged to inform the consumers about the >>>>> paused partitions? That can extend to all group types and prevent future >>>>> fetch calls. >>>>> >>>>> Regards, >>>>> Sushant Mahajan >>>>> >>>>> >>>>> On Wed, 25 Feb 2026, 19:38 Sean Quah via dev, <[email protected]> >>>> wrote: >>>>> >>>>>> Hi Levani, >>>>>> >>>>>> Thank you for the KIP! >>>>>> >>>>>> sq01: Could you outline how the admin client will reset offsets for an >>>>>> active group? After pausing a partition, we have to wait until the >>>>>> partition has been released by its consumer. Will we poll DescribeGroup >>>> or >>>>>> retry OffsetCommits until it succeeds or do something else? >>>>>> >>>>>> Thanks, >>>>>> Sean >>>>>> >>>>>> On Mon, Feb 23, 2026 at 8:53 PM Levani Kokhreidze < >>>> [email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> I’d like to start discussion on KIP-1249 [1] which aims to provide a >>>>>>> better offset reset functionality for the new consumer group rebalance >>>>>>> protocols. >>>>>>> >>>>>>> Looking forward to hear community’s thoughts on this. >>>>>>> >>>>>>> Best, >>>>>>> Levani >>>>>>> >>>>>>> [1] - >>>>>>> >>>>>> >>>> https://cwiki.apache.org/confluence/display/KAFKA/KIP-1249%3A+Better+offset+reset+for+the+new+consumer+group+rebalance+protocol >>>>>>> >>>>>>> >>>>>> >>>> >>>> >
