unbridled-41 opened a new issue, #5124: URL: https://github.com/apache/rocketmq-dashboard/issues/5124
### 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 Aliyun / Tencent Cloud RocketMQ 5.x instances through the provider OpenAPI paths. No live cloud account was called: the evidence is the mock-based service tests (`MetadataServiceTest`) from the revision above. ### Describe the Bug `MetadataService` audits cloud mutations through `executeWithAudit` (`server/src/main/java/org/apache/rocketmq/studio/instance/topic/MetadataService.java:866-888` at the commit above), which skips Apache (`:868-870`) because the Apache admin client records the row itself. Every cloud-capable write goes through that wrapper — `createTopic`, `updateTopic`, `deleteTopic`, group create/update/delete, `resetOffset` and both import loops — except `sendMessage`: ```java 293: public SendMessageVO sendMessage(SendMessageDTO request) { ... 298: return resolve(request.getInstanceId()).sendMessage(request); // no audit call } ``` None of the other layers fills the gap: `AliyunInstanceProvider.sendMessage` (`:478-499`) and `TencentInstanceProvider.sendMessage` (`:590`) contain no `OperationAuditService` call, while the Apache path records `SEND_MESSAGE` for both outcomes in `RocketMQAdminClientImpl` (`:563` success; `:575`, `:578`, `:588` failures; `MESSAGE` as the resource type per `auditResourceType:1202`). A test message sent to a cloud instance therefore leaves no audit row at all. ### Steps to Reproduce With the base revision of the production file in place and the regression tests from the pull request below: ```bash git show origin/rocketmq-studio:server/src/main/java/org/apache/rocketmq/studio/instance/topic/MetadataService.java \ > server/src/main/java/org/apache/rocketmq/studio/instance/topic/MetadataService.java cd server && mvn -o test -Dtest='MetadataServiceTest#cloudSendShouldBeAuditedLikeTheApachePathTest+failedCloudSendShouldBeAuditedWithItsReasonTest+cloudRedeliveryShouldBeAuditedLikeTheApachePathTest' cd .. && git checkout -- server/src/main/java/org/apache/rocketmq/studio/instance/topic/MetadataService.java ``` The tests register a provider for a cloud instance (`vendor = TENCENT`), send a message (success, failure, and through `redeliverMessage`) and capture the audit call. Observed output at that revision: ```text cloudSendShouldBeAuditedLikeTheApachePathTest -- Time elapsed: 1.732 s <<< FAILURE! Wanted but not invoked: operationAuditService.record( "SEND_MESSAGE", "MESSAGE", "orders", "cloud-instance", contains("TagA"), "SUCCESS", isNull() ); -> at org.apache.rocketmq.studio.audit.OperationAuditService.record(OperationAuditService.java:39) Actually, there were zero interactions with this mock. ... [ERROR] Tests run: 3, Failures: 3, Errors: 0, Skipped: 0 ``` ### What Did You Expect to See? One `SEND_MESSAGE` / `MESSAGE` audit row per cloud send attempt, with the topic as the resource name — `SUCCESS` when the provider returns, `FAILED` with the provider's message when it throws. That is the record the same action already produces on an Apache instance, and admission criteria: the three tests above pass and `apacheTopicWriteOperationsShouldNotDuplicateProviderAudit` still holds (the Apache path must not gain a second row). ### What Did You See Instead? Neither the success nor the failure of a cloud send appeared in `/api/audit`. The gap covers more than the send form: `MetadataService.sendMessage` is also the path used by the `rmq.message.send` AI tool (`MessageSendToolHandler`) and by message redelivery (`redeliverMessage:341`), so those operations were unaudited on cloud instances too. ### Additional Context - #4491 (closed) added cloud test-message sending from Topic management; this report is about that path leaving no audit record. - #4656 (open) is the same audit surface but a different operation (cloud imports) and the opposite direction (recorded `SUCCESS` when it failed). - The `SEND_MESSAGE` operation is already part of the console's audit vocabulary (`web/src/pages/ops/auditPresentation.ts`), and the audit schema documents `result` as `SUCCESS`/`FAILED`. Pull request with the fix and the regression tests: #5120 -- 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]
