You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@kafka.apache.org by "Lucy Liu (Jira)" <ji...@apache.org> on 2026/10/13 20:34:00 UTC

[jira] [Resolved] (KAFKA-21151) Extract streams group topology description orchestration into a shared runtime abstraction

     [ https://issues.apache.org/jira/browse/KAFKA-21151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lucy Liu resolved KAFKA-21151.
------------------------------
    Resolution: Fixed

> Extract streams group topology description orchestration into a shared runtime abstraction
> ------------------------------------------------------------------------------------------
>
>                 Key: KAFKA-21151
>                 URL: https://issues.apache.org/jira/browse/KAFKA-21151
>             Project: Kafka
>          Issue Type: Improvement
>    Affects Versions: 4.5.0
>            Reporter: Lucy Liu
>            Assignee: Lucy Liu
>            Priority: Major
>
> The streams-group topology-description plugin's orchestration (push validation, the UNCERTAIN barrier write, plugin invocation and epoch bookkeeping, the periodic cleanup cycle, and the DeleteGroups pre-delete flow) is implemented directly inside GroupCoordinatorService, with its logic tightly coupled to `CoordinatorRuntime<GroupCoordinatorShard, CoordinatorRecord>`
> This split leaves related logic scattered between the two classes and keeps `GroupCoordinatorService` doing state-machine-level work that belongs closer to the component that already owns the plugin and back-off it's driving.
>  We should extract the read/write operations this orchestration needs against streams group state behind a narrow interface, and move the orchestration itself out of `GroupCoordinatorService` and into `StreamsGroupTopologyDescriptionManager,` so all of the topology description plugin's logic, state, and orchestration live in one cohesive class



--
This message was sent by Atlassian Jira
(v8.20.10#820010)