suzhiking opened a new pull request, #23265: URL: https://github.com/apache/kafka/pull/23265
A static consumer that calls `unsubscribe()` suppresses the LeaveGroup RPC in `AbstractCoordinator.maybeLeaveGroup()`, but `resetGenerationOnLeaveGroup()` wiped the local member id anyway. The subsequent rejoin therefore carries `UNKNOWN_MEMBER_ID` while the coordinator still has the member registered under its old id, and the coordinator has to treat such a join as a new process claiming the `group.instance.id`: it evicts the current member and fences its pending join/sync attempts with `FENCED_INSTANCE_ID`. A lone consumer can hit this against itself. If its first blind rejoin is abandoned client-side (for example during a coordinator stall) but was already delivered, the broker still processes it later; whichever of the two joins is processed last fences the other, and the pending attempt of the same consumer receives `FencedInstanceIdException`, which Kafka Streams treats as fatal (`SHUTDOWN_APPLICATION`). See KAFKA-20983 for the full failure sequence observed on a long-running Streams application. The fix keeps the member id whenever no LeaveGroup was actually sent, reusing the existing keep-member-id branch of `resetStateAndGeneration()`. State and generation are still reset and a rejoin is requested exactly as before; only the id retention changes, and only for the suppressed case. The next rejoin then identifies as the existing member and is handled as a recognized rejoin instead of a static replacement, so no ordering of connections and request queues can make a consumer fence itself. Dynamic members and explicit `LEAVE_GROUP` close operations keep the previous behavior. Testing: new regression test `testStaticMemberKeepsMemberIdWhenLeaveGroupIsSuppressed` (static member, DEFAULT membership operation: no LeaveGroup sent, member id retained, generation reset, rejoin requested); `AbstractCoordinatorTest`, `ConsumerCoordinatorTest` and clients checkstyle pass locally. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
