Thanks for the KIP. Overall LGTM.
Can we add a column to the Behavior Matrix for "Classic/static" case?
It might also be useful, to show "existing" vs "new" behavior to make it
easier to compare? Maybe change the rows to:
- close() [current] -> same as close(REMAIN)
- close() [new] -> same as close(DEFAULT)
- close(REMAIN) [current]
- close(REMAIN) [new]
- close(LEAVE) [current]
- close(LEAVE) [new]
And we could use cell background colors to highlight the change for
"streams" protocol and REMAIN case?
-Matthias
On 3/2/26 6:12 AM, 黃竣陽 wrote:
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
