Lucas Brutschy created KAFKA-21389:
--------------------------------------
Summary: ASSIGNMENT_DELAYED stops processing of tasks a streams
member already owns
Key: KAFKA-21389
URL: https://issues.apache.org/jira/browse/KAFKA-21389
Project: Kafka
Issue Type: Bug
Components: clients, streams
Affects Versions: 4.3.0, 4.4.0
Reporter: Lucas Brutschy
When the group coordinator defers computing a new target assignment for a
streams group because the configured assignment interval has not elapsed, it
returns the {{ASSIGNMENT_DELAYED}} status in the heartbeat response. The member
keeps its current assignment in this case. {{StreamsMembershipManager}},
however, treats {{ASSIGNMENT_DELAYED}} like {{MISSING_SOURCE_TOPICS}},
{{MISSING_INTERNAL_TOPICS}} and {{INCORRECTLY_PARTITIONED_TOPICS}} and reports
the group as not ready. The membership manager re-reconciles the unchanged
tasks with {{isGroupReady=false}}, and {{StreamThread}} stops processing,
committing and punctuating all tasks it owns until a later heartbeat no longer
carries the status, which takes up to one heartbeat interval (5 seconds by
default).
This happens both when the heartbeat response carries no task changes and when
the broker echoes the unchanged assignment after the member reports its owned
tasks.
{{ASSIGNMENT_DELAYED}} should not turn a ready member into a not-ready one. It
should keep the readiness of the previous target assignment, so that a member
that has not been ready yet (e.g., during the initial rebalance delay of a new
group) still does not enter {{RUNNING}} with an empty assignment, while a ready
member keeps processing. Missing or incorrectly partitioned topics should still
mark the group as not ready, also when reported together with
{{ASSIGNMENT_DELAYED}}.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
