dajac opened a new pull request, #23552: URL: https://github.com/apache/kafka/pull/23552
Deleting a streams group leaks its topics in the group coordinator's topic-to-groups index (`groupsByTopics`), which `onMetadataUpdate` uses to tell groups that a topic they depend on changed. A streams group's entry in that index is derived from its topology: replaying a `StreamsGroupTopologyValue` record subscribes the group to the topology's required topics and replaying its tombstone unsubscribes it. `StreamsGroup.createGroupTombstoneRecords` wrote the `StreamsGroupMetadataValue` tombstone before the `StreamsGroupTopologyValue` tombstone. On replay, the first one removes the group, so the second one finds no group and returns before unsubscribing anything. The entry survives for the lifetime of the coordinator, and every deleted streams group adds to it. The consumer of the index checks that the group still exists, so the effect is bounded growth of the index and a spurious metadata refresh request on a group that later reuses the id, not a failure. This change writes the topology tombstone before the group epoch tombstone. This restores the invariant the other group types already have: every sibling record is torn down before the epoch tombstone, so the epoch tombstone is the last record of a deletion. Deletions already in the log with the previous order keep leaking on replay until compaction removes their tombstones. The new test builds a streams group with a topology, replays exactly the records that `createGroupTombstoneRecords` produces, and verifies that the group is removed and that the index no longer references it. It fails with the previous record order. -- 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]
