X-LightYear opened a new issue, #4908: URL: https://github.com/apache/rocketmq-dashboard/issues/4908
## Before Creating the Bug Report - [x] I searched the existing Issues and PRs for the same Provider-routing defect. - [x] This defect belongs to RocketMQ Studio. - [x] I reproduced the behavior on `upstream/master`. ## Studio Version - Branch: `master` - Commit: `d50ffecc9d7e8f8f46da64198831bd7952e6974e` - Deployment: built from source ## Describe the Bug Three instance-scoped message operations in `MessageService` bypass `InstanceProviderRegistry` and call the legacy Apache `MessageProvider` directly: - unique-key message lookup - queue-offset listing - message pull by broker queue offset When the selected Studio instance is Aliyun or Tencent, the request is therefore not dispatched through the selected instance provider. It can reach the Apache fallback client instead of reporting the selected provider's supported/unsupported behavior. ## Steps to Reproduce 1. Configure an Aliyun or Tencent instance in Studio. 2. Open the message page or invoke the message query/offset tool for that instance. 3. Request a unique-key lookup, queue offsets, or a message at a physical queue offset. 4. Observe that `MessageService` calls the injected Apache `MessageProvider` without first resolving the instance provider. Deterministic regression test: - `MessageServiceTest.instanceScopedMessageOperationsResolveTheSelectedProviderBeforeFallbackTest` The test makes the instance-provider registry fail with a 501 and verifies that the selected-instance error is propagated and the legacy fallback is never called. On current `upstream/master`, it fails because the code does not consult the registry. ## Expected behavior Every nonblank `instanceId` should be resolved through `InstanceProviderRegistry`. Apache instances should preserve the existing Apache message implementation. Providers that do not support a native operation should return the existing 501 unsupported-operation response rather than invoking an unrelated Apache client. ## Actual behavior `queryMessageByUniqueKey`, `getQueueOffsets`, and `pullMessageAtOffset` call the injected `MessageProvider` directly. The registry is not consulted, so provider selection and provider-specific unsupported-operation semantics are bypassed. ## Root Cause The three methods predate the instance-provider routing used by the neighboring message-query and trace methods. The `InstanceProvider` SPI does not expose these operations, leaving `MessageService` with a direct legacy fallback path even when a nonblank instance id is supplied. ## Scope Add the three native message operations to the instance-provider SPI with the existing unsupported-operation convention, delegate them in `ApacheInstanceProvider`, and route `MessageService` through the registry while preserving the blank-instance legacy fallback. ## Regression evidence The pre-fix focused test failed with `Expecting code to raise a throwable` because the direct fallback returned without consulting the registry. After the fix, the focused and provider suites pass, and negative-space assertions verify that the fallback is not called. -- 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]
