NUAAwqy opened a new issue, #7283: URL: https://github.com/apache/rocketmq-dashboard/issues/7283
### What happened? `MetadataService.consumerGroupConfigurations` filters the provider results with the raw caller-supplied name (`name.equals(group.getName())`), while the search argument it passes to the provider is trimmed internally by `normalizeFilter`. A padded name — e.g. `" my-group "`, which the `rmq.group.detail` AI-tool input schema accepts (it only enforces `minLength: 1`) and `GroupDetailToolHandler` passes verbatim — therefore finds the group in the provider search but fails the exact-match filter, and the read path raises **404 for an existing group**. A blank name likewise produced 404 instead of the 400 that every sibling read path throws. Every sibling name-based path (`findConsumerGroup`, `getGroupSubscriptions`, `getConsumerGroup`, ...) normalizes via `requireName` first; `consumerGroupConfigurations` is the only one that does not. Both methods had no test coverage touching padded or blank names. ### Expected behavior A padded name resolves the same group as the trimmed name, and a blank name is rejected with 400 like the siblings. ### Proposed fix Normalize with `requireName(name, "consumer group name")` before searching and matching — the exact pattern `findConsumerGroup` already uses. I'll submit a PR with regression tests for both the padded and blank cases. -- 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]
