lianetm commented on code in PR #16449: URL: https://github.com/apache/kafka/pull/16449#discussion_r1663408286
########## clients/src/test/java/org/apache/kafka/clients/consumer/internals/MembershipManagerImplTest.java: ########## @@ -2302,6 +2303,61 @@ public void testRebalanceMetricsOnFailedRebalance() { assertEquals(-1d, getMetricValue(metrics, rebalanceMetricsManager.lastRebalanceSecondsAgo)); } + @Test + public void testLeaveGroupWhenStateIsFatal() { + MembershipManagerImpl membershipManager = createMemberInStableState(null); + when(subscriptionState.hasAutoAssignedPartitions()).thenReturn(true); + membershipManager.transitionToFatal(); + assertEquals(MemberState.FATAL, membershipManager.state()); + + subscriptionState.assignFromUser(Collections.singleton(new TopicPartition("topic", 0))); + assertEquals(1, subscriptionState.numAssignedPartitions()); Review Comment: I'm not sure we would ever be able to achieve this path we're mocking here with a real consumer, so wondering if this is even a valid scenario to test? (this test, and the ones below for fenced and stale too). A member in fatal/fenced/stale state means it was part of a group (automatic assignment after subscribe), and then we're mocking a manual assignment and takes effect and is cleared on leaveGroup. I expect that would never be possible because the consumer does not allow to mix the subscription types, so the call to assign would fail before actually updating the assignment and numAssignedPartitions (a consumer would have to unsubscribe or assign with empty to then be able to manually assign the topic0 partition) Just for the record, I totally see the value in the `testLeaveGroupWhenStateIsUnsubscribe`, which is covering the gap we had and it's a valid combination since it's not mixing subscription types, but I struggle to see this call to assign happening when a member is fatal/fenced/stale? -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org