chickenchickenlove commented on code in PR #24003:
URL: https://github.com/apache/kafka/pull/24003#discussion_r4407160115
##########
clients/src/test/java/org/apache/kafka/clients/consumer/internals/StreamsMembershipManagerTest.java:
##########
@@ -2487,6 +2487,68 @@ public void testIsGroupReadyChangeWhenTasksAreNull() {
completeAssignment(tasksAssignedEvent2);
}
+ @Test
+ public void testAssignmentDelayedKeepsReadyGroupReady() {
Review Comment:
Could we add two more test cases to cover the readiness preservation here?
- `ASSIGNMENT_DELAYED` while an assignment callback is pending. Start with
`currentAssignment.isGroupReady != targetAssignment.isGroupReady`, receive a
delayed response, then complete the pending callback and generate the ACK.
Verify that the latest target readiness is preserved, with no additional
assignment callback. Covering both directions would distinguish the intended
behavior from accidentally using `currentAssignment.isGroupReady`; the current
tests have already completed reconciliation when the delayed response arrives.
- `ASSIGNMENT_DELAYED` with a non-null, unchanged assignment while `STABLE`.
Complete reconciliation, generate the `ACK` to transition to `STABLE`, then
receive the delayed response with the same task sets. Verify that the member
stays ready and `STABLE` without another assignment callback. This matches a
possible broker response: it echoes the assignment when owned tasks are
reported, even while computing the next target assignment is delayed.
What do you think?
--
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]
