X-LightYear opened a new issue, #4989:
URL: https://github.com/apache/rocketmq-dashboard/issues/4989
### Before Creating the Bug Report
- [x] I searched the open and closed issues and did not find the same cloud
Topic route lookup path.
- [x] This is a defect in RocketMQ Studio.
- [x] The behavior is reproducible on the current `rocketmq-studio` branch.
### Problem
`MetadataService.getTopicRoutes(instanceId, name)` always delegates to the
Apache
`MetadataProvider`, even when `instanceId` resolves to an Aliyun or Tencent
instance. The instance provider SPI does not expose Topic route lookup for
cloud
providers, so the service should reject the unsupported operation at its
instance boundary instead of invoking an Apache-only collaborator.
This makes the cloud route endpoint depend on the Apache runtime admin path
and
can surface an unrelated broker/client failure (or a null route result in a
mock/provider boundary) instead of a deterministic unsupported-operation
response.
### Reproduction
1. Configure a cloud instance, for example `cloud-instance`.
2. Request `GET /api/topics/{name}/routes?instanceId=cloud-instance`.
3. Observe that `MetadataService` invokes the Apache `MetadataProvider`
rather
than rejecting the request according to the selected instance vendor.
The deterministic regression test
`MetadataServiceTest.topicRoutesShouldRejectCloudInstancesBeforeUsingApacheMetadataProvider`
fails on the current production code because no exception is raised and the
Apache metadata provider is reached.
### Expected behavior
Cloud Topic route lookup should fail fast with HTTP 501 and should not
invoke the
Apache metadata provider.
### Actual behavior
The cloud instance is sent through the Apache metadata-provider path. The
result
or failure therefore depends on an Apache runtime client being usable for the
cloud instance rather than on the selected provider's supported capabilities.
### Scope
The defect is confined to the Topic route service boundary. No broker
behavior
or persistence schema is involved.
### 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]