lucasbru opened a new pull request, #24003: URL: https://github.com/apache/kafka/pull/24003
The group coordinator returns `ASSIGNMENT_DELAYED` in two situations: during the initial rebalance delay of a new streams group, and when it defers computing a new target assignment because the configured assignment interval has not elapsed yet. In the second case the member keeps its current assignment, but `StreamsMembershipManager` mapped the status to `isGroupReady=false`. The membership manager then re-reconciled the unchanged tasks as not ready, and `StreamThread` skipped processing, committing and punctuating for all owned tasks until a later heartbeat (up to one heartbeat interval) no longer carried the status. With this change, `ASSIGNMENT_DELAYED` on its own keeps the readiness of the previous target assignment. Since the target assignment starts out not ready and is reset when the member leaves or is fenced, a member that has not been ready yet, including one waiting out the initial rebalance delay, still does not enter `RUNNING` with an empty assignment. A ready member keeps processing the tasks it owns. Missing or incorrectly partitioned topics still mark the group as not ready, also when reported together with `ASSIGNMENT_DELAYED`. The new unit tests in `StreamsMembershipManagerTest` reproduce the issue (a ready member owning a task receiving a second tasks-assigned event with `isGroupReady=false`) and cover the combination with a missing-topics status. The existing test for a ready/not-ready transition without task changes now uses `MISSING_SOURCE_TOPICS`, since it previously asserted the behaviour being fixed. -- 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]
