[
https://issues.apache.org/jira/browse/KAFKA-14922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18096588#comment-18096588
]
Preethi KCS edited comment on KAFKA-14922 at 7/15/26 7:40 PM:
--------------------------------------------------------------
No [~alisa23]. I was traveling last week, hence couldn't get to work on it.
I'm currently working on the PR changes as mentioned in my message above.
Facing an issue while working on test cases.
I noticed that moving this validation - {{validateApplicationIdExists()}} to
the start of {{execute()}} causes certain test to fail. These tests use a new
{{application.id}} ({{{}safeUniqueTestName{}}}) but don't create a consumer
group. Previously, {{maybeDeleteActiveConsumers()}} treated a missing group as
a no-op, so execution continued to the code that defaults
{{GROUP_PROTOCOL_CONFIG}} to {{CLASSIC}} (or accepts an explicitly configured
{{CLASSIC}} value). With the new validation, execution exits before that logic
is reached. FAIL FAST
[https://github.com/apache/kafka/pull/21826#discussion_r3383831222]
*Before the proposed change:*
execute()
↓
maybeDeleteActiveConsumers(appID)
↓
application.id doesn't exist
↓
GroupIdNotFoundException treated as no-op
↓
continue execution
↓
GROUP_PROTOCOL_CONFIG logic runs
↓
overwrite/default to CLASSIC
↓
return 0
*After the proposed change:*
execute()
↓
validateApplicationIdExists(appID)
↓
application.id doesn't exist
↓
throw IllegalArgumentException
↓
return EXIT_CODE_ERROR
Should these tests be updated to create a valid consumer group?
Test names: shouldDefaultToClassicGroupProtocol,
shouldAllowGroupProtocolClassic, shouldOverwriteGroupProtocolOtherThanClassic
was (Author: JIRAUSER312624):
No [~alisa23]. I was traveling last week, hence couldn't get to work on it.
I'm currently working on the PR changes as mentioned in my message above.
Facing an issue while working on test cases.
I noticed that moving this validation - {{validateApplicationIdExists()}} to
the start of {{execute()}} causes certain test to fail. These tests use a new
{{application.id}} ({{{}safeUniqueTestName{}}}) but don't create a consumer
group. Previously, {{maybeDeleteActiveConsumers()}} treated a missing group as
a no-op, so execution continued to the code that defaults
{{GROUP_PROTOCOL_CONFIG}} to {{CLASSIC}} (or accepts an explicitly configured
{{CLASSIC}} value). With the new validation, execution exits before that logic
is reached. FAIL FAST
https://github.com/apache/kafka/pull/21826#discussion_r3383831222
*Before the proposed change:*
execute()
↓
maybeDeleteActiveConsumers(appID)
↓
application.id doesn't exist
↓
GroupIdNotFoundException treated as no-op
↓
continue execution
↓
GROUP_PROTOCOL_CONFIG logic runs
↓
overwrite/default to CLASSIC
↓
return 0
*After the proposed change:*
execute()
↓
validateApplicationIdExists(appID)
↓
application.id doesn't exist
↓
throw IllegalArgumentException
↓
return EXIT_CODE_ERROR
Should these tests be updated to create a valid consumer group?
> 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)
