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 that
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
