Skip to content

Conversation

@lucasbru
Copy link
Member

@lucasbru lucasbru commented Feb 9, 2026

Summary

When using the streams group protocol (group.protocol=streams), the
consumer always leaves the group on close, regardless of whether
REMAIN_IN_GROUP was specified. This differs from the classic protocol
behavior where the consumer does not leave the group explicitly by
default.

This PR documents this behavior in the javadocs for
CloseOptions.GroupMembershipOperation, KafkaStreams.close(), and
KafkaStreams.close(Duration), and adds an INFO log message when a
close occurs with the streams protocol to inform users about this
behavior.

Test plan

  • Verified checkstyle and spotlessCheck pass
  • Documentation-only changes with minor log addition

Reviewers: Matthias J. Sax matthias@confluent.io

When using the streams group protocol (group.protocol=streams), the consumer always leaves the group on close, regardless of whether REMAIN_IN_GROUP was specified. This commit documents this behavior in the javadocs for CloseOptions, KafkaStreams.close(), and KafkaStreams.close(Duration), and adds an INFO log message when this occurs.
@lucasbru lucasbru requested a review from mjsax February 9, 2026 14:14
@github-actions github-actions bot added streams small Small PRs labels Feb 9, 2026
Copy link
Member

@mjsax mjsax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall LGTM. Just a nit question. Feel free to merge either way.

try {
final GroupMembershipOperation membershipOperation =
leaveGroupRequested.get() == org.apache.kafka.streams.CloseOptions.GroupMembershipOperation.LEAVE_GROUP ? LEAVE_GROUP : REMAIN_IN_GROUP;
if (membershipOperation == REMAIN_IN_GROUP && streamsRebalanceData.isPresent()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not 100% sure about re-using streamsRebalanceData.isPresent() -- Sure it works, but is it "clean"?

Should we rather introduce a member-variable (eg GroupProtocol rebalanceProtocol)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pattern streamsRebalanceData.isPresent() is already used throughout this file to check for the streams protocol (lines 1122, 1128, 1178, 1332, 1503). Introducing a separate GroupProtocol member variable would add redundancy since streamsRebalanceData is only populated when using the streams protocol.

If you think we should change the pattern, it would be a larger cleanup across the file. Happy to do that as a separate PR if you prefer, but for this minor doc change I'd prefer to stay consistent with the existing pattern.

@lucasbru lucasbru merged commit 053330c into apache:trunk Feb 11, 2026
26 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants