Aias00 opened a new issue, #4375:
URL: https://github.com/apache/rocketmq-dashboard/issues/4375
## Problem
The message-detail dialog always renders the direct-consume action for every
selected instance, but
only `ApacheInstanceProvider` implements `consumeMessageDirectly`. Aliyun
and Tencent providers
inherit the default HTTP 501 response, so cloud operators only discover the
unsupported state after
opening and submitting the dialog.
This is a follow-up to #2507 / #2508, which intentionally implemented Apache
only and listed cloud
providers as out of scope. It is not covered by #3109, which only trims
fields before the Apache
broker call. No cloud-provider direct-consume implementation PR exists.
Both supported 5.x cloud providers now expose an official equivalent, and
the SDK versions already
declared by Studio contain the required methods:
- Aliyun RocketMQ 5.x `VerifyConsumeMessage`:
https://help.aliyun.com/zh/apsaramq-for-rocketmq/cloud-message-queue-rocketmq-5-x-series/developer-reference/api-rocketmq-2022-08-01-verifyconsumemessage
- Tencent Trocket 5.x `VerifyMessageConsumption`:
https://cloud.tencent.com/document/api/1493/126163
## Proposed design
### Capability contract
Add `DIRECT_MESSAGE_CONSUME` to the shared `InstanceCapability` contract and
TypeScript union.
Apache, Aliyun 5.x, and Tencent 5.x providers advertise it only when they
implement the operation.
`MessageService` checks the selected provider capability before invoking the
write operation. This
keeps the API fail-closed for future providers even if the UI is bypassed.
### Aliyun provider
Build `VerifyConsumeMessageRequest` from the resolved cloud instance plus
the existing DTO fields:
`topicName`, `messageId`, `consumerGroupId`, and `clientId`. Execute it
through
`AliyunClientFactory.call` so timeout and cloud error mapping remain
consistent.
- `success=true` and `data=true` map to `CR_SUCCESS`.
- A complete business response with false success/data maps to `CR_FAILED`
and retains the cloud
message/request id in the remark.
- A null/incomplete response is a 502, not a fabricated success.
### Tencent provider
Build `VerifyMessageConsumptionRequest` with `InstanceId`, `Topic`, `MsgId`,
`ConsumerGroup`, and
`ClientId`. Execute it through `TencentClientFactory.call`.
Tencent returns a request id rather than a consume-result body; a completed
SDK call maps to
`CR_SUCCESS` and includes the request id in the remark. A null response is a
502.
For both providers, measure local request duration for `spentTimeMillis`.
`order` and `autoCommit`
remain false because the cloud APIs do not expose those Apache-specific
result fields.
### Web gating
The Message page loads `/instances/{id}/capabilities` for the selected
instance and renders the
direct-consume action only after `DIRECT_MESSAGE_CONSUME` is confirmed.
Capability errors, missing
capabilities, and stale responses after an instance switch all fail closed.
The backend capability
guard remains authoritative.
## Scope
- Apache RocketMQ, Aliyun RocketMQ 5.x, and Tencent Trocket 5.x providers.
- No new dependency.
- Aliyun/Tencent 4.x APIs are out of scope because the current Studio
providers target 5.x SDKs.
## Test plan
- Provider tests capture every Aliyun/Tencent request field and verify
success/failure/null mapping.
- Capability tests prove all implemented providers advertise the operation.
- Service tests reject a provider without the capability before invoking it
and preserve auditing for
supported calls.
- Message-page tests cover capability loading, supported visibility,
unsupported/error fail-closed
behavior, and stale instance responses.
- Run focused backend/frontend tests, Java 21 backend
suite/build/checkstyle, frontend suite/build/lint,
independent review, and `git diff --check`.
--
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]
