smjn commented on PR #18976: URL: https://github.com/apache/kafka/pull/18976#issuecomment-2787503527
> This PR is really quite close now, but there is one issue which I found during testing. > > Imagine that I have a share group SG1 which has the following offset information. > > ``` > bin/kafka-share-groups.sh --bootstrap-server localhost:9092 --group console-share-consumer --describe > > GROUP TOPIC PARTITION START-OFFSET > console-share-consumer T1 0 11 > ``` > > When there are no members, I am able to delete the offsets for T1. > > However, if I delete the offsets for a different topic, say T2, then it actually writes a `ShareSnapshot` tombstone for T2, even though T2 is not one of the initialized topics for this share group. This is probably harmless, but it's definitely wrong. > > @smjn This PR probably ought to be checking the set of initialized topics before it issues the deletions to the persister, or the persister should be catching the deletions for uninitialized topics and returning an error code rather than writing the tombstones. What do you think? I think a warning on share coordinator side and idempotent operation should sufficient. Error code will not add any value. -- 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: jira-unsubscr...@kafka.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
