Hi Sean, sq01: Excellent point! I think the simplest approach would be to omit assignment epochs from current assignment records for static members that have left temporarily (memberEpoch = -2). When loading the record, treat it exactly like a legacy record; Assume all assignment epochs equal the member epoch (-2). Partitions would then be considered assigned to the new member ID "from the start."
Cheers, Lucas On Sat, Jan 3, 2026 at 9:49 PM Sean Quah via dev <[email protected]> wrote: > > Hi Lucas, > Thanks for the KIP! > > sq01: Do you think we could describe what happens when a static member is > replaced? The new static member will inherit the previous member's > assignment, but will we also inherit the previous assignment epoch or reset > it to the new member's epoch? > > Thanks, > Sean > > On Thu, Dec 18, 2025 at 8:00 PM Lucas Brutschy via dev <[email protected]> > wrote: > > > Hi all, > > > > I posted a new KIP to add assignment epochs to KIP-848-style consumer > > groups. The idea is to avoid failing offset commits in the new > > consumer protocol by relaxing the member epoch validation slightly. > > > > Please take a look and let me know what you think: > > > > > > https://cwiki.apache.org/confluence/display/KAFKA/KIP-1251%3A+Assignment+epochs+for+consumer+groups > > > > Cheers, > > Lucas > >
