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
