[
https://issues.apache.org/jira/browse/KAFKA-14922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18094077#comment-18094077
]
Alieh Saeedi commented on KAFKA-14922:
--------------------------------------
[~mjsax] [~preethikcs]
Regarding having 2 --force options: I agree that the two scenarios are mutually
exclusive in practice. If the group doesn't exist, there are no members to
remove. if there are active members, the group obviously exists. So a single
--force never actually triggers "the wrong one" of the two behaviors — the
coupling is theoretical, not operational. The trade-off is really simplicity +
no KIP versus more explicit self-documenting flags at the cost of process and
surface area. So I think my review comment in the PR is not accurate.
I was thinking about this a bit more. The current fix addresses part of the
problem, but it can never be fully exact. Could we additionally make future
apps 100% safe by introducing a reserved delimiter in internal topic names,
e.g. `<appId>.reserved-delimiter.<name>-<suffix>` (with `.reserved-delimiter.`
rejected in `application.id`)? That would make the app-id boundary
unambiguously parseable. It would have to be opt-in for new apps only (existing
topics can't be renamed) and would need a KIP — so maybe it's too much for this
ticket, but I wanted to raise it. WDYT?
> kafka-streams-application-reset deletes topics not belonging to specified
> application-id
> ----------------------------------------------------------------------------------------
>
> Key: KAFKA-14922
> URL: https://issues.apache.org/jira/browse/KAFKA-14922
> Project: Kafka
> Issue Type: Bug
> Components: streams, tools
> Affects Versions: 3.4.0
> Reporter: Jørgen
> Assignee: Preethi KCS
> Priority: Major
> Labels: beginner, needs-kip, newbie
>
> Slack-thread:
> [https://confluentcommunity.slack.com/archives/C48AHTCUQ/p1681908267206849]
> When running the command _kafka-streams-application-reset --bootstrap-servers
> $BOOTSTRAP --application-id foo_ all internal topics that _starts with_ foo
> is deleted. This happens even if there's no application-id named foo.
> Example:
> {code:java}
> Application IDs:
> foo-v1
> foo-v2
> Internal topics:
> foo-v1-repartition-topic-repartition
> foo-v2-repartition-topic-repartition
> Application reset:
> kafka-streams-application-reset --bootstrap-servers $BOOTSTRAP
> --application-id foo
> > No input or intermediate topics specified. Skipping seek.
> Deleting inferred internal topics [foo-v2-repartition-topic-repartition,
> foo-v1-repartition-topic-repartition]
> Done.{code}
> Expected behaviour is that the command fails as there are no application-id's
> with the name foo instead of deleting all foo* topics.
> This is critical on typos or if application-ids starts with the same name as
> others (for example if we had foo-v21 and wanted to reset foo-v2)
> The bug should be located here:
> [https://github.com/apache/kafka/blob/c14f56b48461f01743146d58987bc8661ba0d459/tools/src/main/java/org/apache/kafka/tools/StreamsResetter.java#L693]
> Should check that the topics matches the application-id exactly instead of
> checking that it starts with the application-id.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
