X-LightYear opened a new issue, #4549: URL: https://github.com/apache/rocketmq-dashboard/issues/4549
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: master git commit id: d50ffecc9d7e8f8f46da64198831bd7952e6974e deployed as: docker compose ### Runtime Environment OS: Windows 11 MySQL: not required for the deterministic unit regression browser: Google Chrome 127.0.6533.120 (64-bit) on Windows 11 ### Connected RocketMQ Cluster RocketMQ version: 5.5.0 access mode: Apache instance metadata provider deployment: docker compose from deploy/rocketmq ### Build Toolchain _No response_ ### Describe the Bug The paginated Topic and Consumer Group APIs accept both `instanceId` and `clusterId`, but the `clusterId` filter is lost on the instance-scoped pagination path. When one Studio instance contains metadata from multiple RocketMQ clusters, requests scoped to a specific cluster can therefore return Topics or Consumer Groups belonging to other clusters under the same instance. This also makes the pagination `total` inconsistent with the requested cluster scope. ### Steps to Reproduce Assume one Studio instance contains resources from two RocketMQ clusters. For Topics: | Topic | instanceId | clusterId | |---|---|---| | orders-a | instance-a | cluster-a | | orders-b | instance-a | cluster-b | Request: `GET /api/topics/page?instanceId=instance-a&clusterId=cluster-a&page=1&pageSize=20` For Consumer Groups: | Consumer Group | instanceId | clusterId | |---|---|---| | group-a | instance-a | cluster-a | | group-b | instance-a | cluster-b | Request: `GET /api/groups/page?instanceId=instance-a&clusterId=cluster-a&page=1&pageSize=20` Both cases are reproducible deterministically through `MetadataService` unit tests. ### What Did You Expect to See? When both `instanceId=instance-a` and `clusterId=cluster-a` are supplied, pagination should only operate on resources belonging to `cluster-a`. For Topics: - items: `[orders-a]` - total: `1` For Consumer Groups: - items: `[group-a]` - total: `1` ### What Did You See Instead? The Topic pagination result contains resources from both clusters: - items: `[orders-a, orders-b]` - total: `2` The Consumer Group pagination result behaves the same way: - items: `[group-a, group-b]` - total: `2` The `clusterId` filter is lost before the underlying metadata pagination query is executed. ### Additional Context The issue is caused by the instance-scoped pagination provider contract. Topic path: `TopicController` → `MetadataService.listTopicsPage(instanceId, clusterId, ...)` → `InstanceProvider.listTopicsPage(instanceId, type, search, ...)` → `ApacheInstanceProvider` → `MetadataProvider.listTopicsPage(instanceId, null, ...)` Consumer Group path: `MetadataService.listConsumerGroupsPage(instanceId, clusterId, ...)` → `InstanceProvider.listConsumerGroupsPage(instanceId, search, ...)` → `ApacheInstanceProvider` → `MetadataProvider.listConsumerGroupsPage(instanceId, null, ...)` `MetadataService` receives `clusterId`, but the instance-scoped pagination methods in `InstanceProvider` do not expose that parameter. The Apache provider therefore forwards `null` as the cluster filter even though the underlying metadata provider already supports cluster-scoped pagination. The non-paginated paths also preserve the cluster filter, so the paginated behavior is inconsistent with the existing API semantics. Two deterministic regression tests were added locally in: `server/src/test/java/org/apache/rocketmq/studio/instance/topic/MetadataServiceTest.java` Tests: - `listTopicsPageShouldApplyClusterFilterForInstanceScopedQueriesTest` - `listConsumerGroupsPageShouldApplyClusterFilterForInstanceScopedQueriesTest` Current master result: ```text Tests run: 54 Failures: 2 Errors: 0 ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
