unbridled-41 opened a new issue, #5123: URL: https://github.com/apache/rocketmq-dashboard/issues/5123
### 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: rocketmq-studio git commit id: 4ee173ad71ae777f01111394a88358958b9abad6 deployed as: built from source; the evidence below is the repository's own test suite run against that revision, not a deployed instance ``` ### Runtime Environment ``` OS: Ubuntu on Linux 6.6.87.2-microsoft-standard-WSL2 JDK: OpenJDK 21.0.12.1 Maven: 3.8.7 (offline) MySQL: not available in this environment, so the MySQL-backed *IntegrationTest classes are not part of the evidence ``` ### Connected RocketMQ Cluster Tencent Cloud RocketMQ 5.x through the provider OpenAPI path. No live cloud account was called: the evidence is the mock-based provider/service tests (`MessageServiceTest`, `TencentInstanceProviderTest`) from the revision above. ### Describe the Bug `MessageService.auditResult` (`server/src/main/java/org/apache/rocketmq/studio/instance/message/MessageService.java:205-207` at the commit above) treats every consume-result spelling except the broker-side `CR_SUCCESS` as a failure: ```java return "CR_SUCCESS".equals(consumeResult) ? "SUCCESS" : "FAILED"; ``` The Tencent direct-consume path does not answer with a broker `CMResult`: after a successful `VerifyMessageConsumption` OpenAPI call it returns `consumeResult = "REQUEST_ACCEPTED"` with the remark "Tencent accepted the verification request; the consumption outcome is not returned" (`TencentInstanceProvider.consumeMessageDirectly`). `docs/api-spec.md` §8 documents the same vocabulary: Aliyun answers `CR_SUCCESS`/`CR_FAILED`, while "Tencent 因 OpenAPI 不回传消费结果固定为 `REQUEST_ACCEPTED`，实际语义见 `remark`". Because the mapping only knows the broker spelling, an accepted cloud operation is written to `rmq_operation_audit` with `result = FAILED`. ### Steps to Reproduce With the base revision of the production file in place and the regression test from the pull request below: ```bash git show origin/rocketmq-studio:server/src/main/java/org/apache/rocketmq/studio/instance/message/MessageService.java \ > server/src/main/java/org/apache/rocketmq/studio/instance/message/MessageService.java cd server && mvn -o test -Dtest='MessageServiceTest#auditsACloudAcceptedDirectConsumeAsSuccessTest' cd .. && git checkout -- server/src/main/java/org/apache/rocketmq/studio/instance/message/MessageService.java ``` The test registers a provider for a Tencent instance whose `consumeMessageDirectly` returns `consumeResult = "REQUEST_ACCEPTED"` and captures the audit call. Observed output at that revision: ```text Argument(s) are different! Wanted: operationAuditService.record( "DIRECT_CONSUME_MESSAGE", "MESSAGE", "msg-1", "tencent-instance", contains("REQUEST_ACCEPTED"), "SUCCESS", isNull() ); Actual invocations have different arguments at position [5]: operationAuditService.record( "DIRECT_CONSUME_MESSAGE", "MESSAGE", "msg-1", "tencent-instance", "topic=orders, consumerGroup=billing, clientId=client-a, result=REQUEST_ACCEPTED", "FAILED", null ); ``` ### What Did You Expect to See? The audit row should grade the operation the way the console did — as performed — while keeping the vendor semantics in the same row, i.e. `result = SUCCESS` with the detail still containing `result=REQUEST_ACCEPTED`, exactly as `docs/api-spec.md` documents that spelling. Genuine failures must keep mapping to `FAILED` (`CR_FAILED`, `CR_ROLLBACK`, unknown values, and the thrown-exception path at `MessageService.java:185`). ### What Did You See Instead? The console recorded `FAILED` for an operation that it had just reported as accepted. The audit page renders that value as a failed operation, the result filter offers `FAILED` for it, and the same mapping is what labels a genuinely failed consume, so the two outcomes cannot be told apart in the trail. ### Additional Context - #4608 (closed) was the opposite direction — direct consume audited `SUCCESS` when the consume failed — and was fixed by #4607, which introduced the mapping quoted above. This report is about the cloud vocabulary that fix did not cover, not about its intent. - #4656 (open) is about cloud **import** auditing, a different operation. Pull request with the fix and the regression test: #5119 -- 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]
