RockteMQ-AI commented on issue #10556: URL: https://github.com/apache/rocketmq/issues/10556#issuecomment-4828899815
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** The reported issue has been verified against the current codebase (develop branch). **Root Cause:** `findOneBroker(String topic)` in `ClusterMetadataService` is designed to look up brokers by **topic route** (it calls `topicRouteService.getAllMessageQueueView(ctx, topic)` internally). However, three `CacheLoader.getDirectly()` methods pass `config.getRocketMQClusterName()` (a cluster name like `DEFAULT_CLUSTER`) instead of a valid topic name: - `ClusterSubscriptionGroupConfigCacheLoader.getDirectly()` (line 186) - `ClusterUserCacheLoader.getDirectly()` (line 126) - `ClusterAclCacheLoader.getDirectly()` (line 139) Since NameServer has no topic route for the cluster name string, `getAllMessageQueueView()` returns an empty result, causing the "no topic route from namesrv" error. **Why tests pass:** `BaseServiceTest.java` line 82 explicitly mocks `getAllMessageQueueView(any(), eq(CLUSTER_NAME))` to return valid data, masking the real-world failure. **Impact:** Proxy fails to load subscription group configs, user ACL data, and user metadata when starting in cluster mode. **Severity:** High — affects proxy startup in standard deployments. **Suggested Fix:** Use a known system topic (e.g., `MixAll.DEFAULT_TOPIC` / `TBW102`) or `topicRouteService.getBrokerAddr()` to obtain a broker address, rather than passing the cluster name as a topic to `findOneBroker()`. --- *Automated evaluation by RockteMQ-AI* -- 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]
