frankvicky commented on code in PR #18737:
URL: https://github.com/apache/kafka/pull/18737#discussion_r1954461908
##########
clients/src/test/java/org/apache/kafka/clients/consumer/internals/ConsumerMembershipManagerTest.java:
##########
@@ -663,7 +663,7 @@ public void
testSameAssignmentReconciledAgainWithMissingTopic() {
// stay in RECONCILING state, since an unresolved topic is assigned
membershipManager.onHeartbeatSuccess(createConsumerGroupHeartbeatResponse(assignment1,
membershipManager.memberId()));
assertEquals(MemberState.RECONCILING, membershipManager.state());
- membershipManager.poll(time.milliseconds());
+ membershipManager.maybeReconcile(true);
Review Comment:
Hey @lianetm,
I have some questions regarding the invocations of `maybeReconcile` during
the review.
Before the patch, there was no `canCommit` argument, so all tests ran `full
reconciliation` when invoking `maybeReconcile`. All these test cases were built
on this assumption.
Given that, I'm wondering whether we should:
1. Change the existing tests to invoke `maybeReconcile(false)`, or
2. Add separate test cases for `maybeReconcile(false)`
The reason I raise these questions is that there is significant state
transition logic behind the `if (autoCommitEnabled && !canCommit)` condition.
Changing the invocation to `maybeReconcile(false)` would cause many assertions
to fail. I'm concerned whether such changes would compromise the original
intent of these test cases.
--
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
