Hello Sanghyeok An, Thanks for the feedback,
The consumer already has corresponding close semantics that differentiate behavior based on membership, and in that context I agree that having static members remain in the group by default is reasonable and consistent with the goal of static membership. Based on this, I plan to make the behavior explicit in the KIP: under the Streams Protocol, CloseOptions.DEFAULT will resolve to remain in group for static members, while keeping the existing behavior for dynamic members. Best Regards, Jiunn-Yang > Sanghyeok An <[email protected]> 於 2026年2月27日 晚上10:57 寫道： > > Hi Jiunn-Yang, > Thanks for the this KIP. > > I have a small question. > > ash01 : > Would it be worth considering mapping CloseOptions.DEFAULT differently not > only based on the protocol, but also on whether the member is static? > > I recently worked on a server-side implementation of static membership for > KIP-1071. > Once static members are supported under the Streams Protocol, DEFAULT close > semantics may reasonably differ between dynamic and static members. > > For dynamic members, I agree with the KIP rationale that remaining in the > group provides no real benefit, so having DEFAULT map to a leave behavior > under the Streams Protocol makes sense. > However, for static members, making leave the default would weaken the > primary benefit of static membership, minimizing rebalances on restart. > > Would it make sense to resolve DEFAULT under the Streams Protocol as follows? > - dynamic member: DEFAULT maps to consumer CloseOptions.DEFAULT (leave) > - static member: DEFAULT maps to consumer CloseOptions.REMAIN_IN_GROUP > (remain) > > This would keep the no-arg KafkaStreams.close() as a safer default in both > cases, while still reserving REMAIN_IN_GROUP as an explicit user intent. > Curious what you think, and whether this should be in scope for this KIP or > tracked as a follow-up. > > Thanks for reading this! > > Best Regards > Sanghyeok An > > -----Original Message----- > From: "Lucas Brutschy via dev"<[email protected]> > To: <[email protected]>; > Cc: "Lucas Brutschy"<[email protected]>; > Sent: 2026-02-24 (화) 21:26:47 (GMT+09:00) > Subject: Re: [DISCUSS] KIP-1284 Introduce CloseOptions.DEFAULT for Kafka > Streams > > Hi Jiunn-Yang, > > Thanks for the update; it looks good to me. > > Cheers, > Lucas > > On Tue, Feb 24, 2026 at 12:33 PM 黃竣陽 <[email protected]> wrote: >> >> Hi Lucas, >> >> Thanks for your feedback, I have updated the KIP. >> >> Best Regards, >> Jiunn-Yang >> >>> Lucas Brutschy via dev <[email protected]> 於 2026年2月23日 晚上11:00 寫道： >>> >>> Hi Jiunn-Yang, >>> >>> Thanks for the KIP! I think it's correct and pretty much reflects what >>> was written in the ticket. >>> >>> One thing to point out explicitly is that there _is_ a behavioral >>> change. People using REMAIN_IN_GROUP explicitly now with streams >>> groups, the member left before theis KIP and will remain with this >>> KIP. However, I think this is rarely used because it explicitly states >>> the (old) default. Specifically with KIP-1071, I don't think many >>> people will use it. I consider the behavioral change here more a bug >>> fix that we are implementing as part of this KIP, but I would still >>> point it out in the KIP. >>> >>> Thanks, >>> Lucas >>> >>> >>> >>> On Mon, Feb 23, 2026 at 2:32 PM 黃竣陽 <[email protected]> wrote: >>>> >>>> Hello everyone, >>>> >>>> I would like to start a discussion on KIP-1284 Introduce >>>> CloseOptions.DEFAULT for Kafka Streams >>>> <https://cwiki.apache.org/confluence/x/1ow8G> >>>> >>>> This proposal aims to introduce CloseOptions.DEFAULT to resolve semantic >>>> inconsistency >>>> in KafkaStreams shutdown behavior across protocols. >>>> >>>> Best regards, >>>> Jiunn-Yang >>
