Frun1na opened a new issue, #6540: URL: https://github.com/apache/rocketmq-dashboard/issues/6540
### 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 `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `779b8c0e` deployed as: reproduced by unit tests against that commit (the affected code is the backend services) ### Runtime Environment OS: Ubuntu on WSL2 MySQL: not applicable — the defect is the result value written to `rmq_operation_audit`; the summary that drops the row is also unit-tested browser: not applicable — reproduced in JUnit 5 service tests ### Connected RocketMQ Cluster RocketMQ version: not applicable — one of the affected paths returns before any broker call (missing DLQ topic) and the others are audited after the broker/webhook attempt, with stubbed clients in the tests access mode: not applicable deployment: not applicable ### Describe the Bug The audit result vocabulary is `SUCCESS` / `FAILED` / `PARTIAL` — declared in the api-spec vocabulary table (`docs/api-spec.md`, "审计结果") and implemented by `MybatisPlusAuditRepository.summarize`, which fills only `successful` / `failed` / `partial` and takes `total` from every matching row. Three writers store other words, so their rows are counted in the total and in no bucket (the exact gap #4657 fixed for one branch): - `NotificationOutboxService.retry` (`server/src/main/java/org/apache/rocketmq/studio/ops/alert/NotificationOutboxService.java:540`) audits a retry-wait delivery as `RETRYING` — #4657's own message records this as a follow-up: "`\"RETRYING\"` in the same file has the same total-vs-bucket gap and is left for a follow-up". - `RocketMQDLQProvider` audits a resend whose DLQ topic does not exist as `NOT_FOUND` (`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQDLQProvider.java:226`). - The same provider audits a resend that matched no dead letters as `NO_MESSAGES` (`:241`, `:311`), the value `classifyOutcome` (`:788-801`) returns for that case. The audit page's per-result breakdown therefore reports a distribution whose bucket counts do not add up to the `total` of the same response, and the result filter offers values no bucket counts. ### Steps to Reproduce 1. Trigger a DingTalk/SMS/email delivery whose webhook rejects the payload (or configure none) so the outbox schedules a retry, then `GET /api/audit-logs/summary`: `total` grew by one, `failed` did not. 2. Resend a consumer group's DLQ where the group never dead-lettered a message, or where the window matches nothing: the same gap, with `NOT_FOUND` / `NO_MESSAGES` in the stored row. 3. Without a running server: `NotificationOutboxServiceTest.retriesDingTalkDeliveryWhenTheRobotRejectsThePayloadTest` and `RocketMQDLQProviderTest.resendMessagesDoesNotPullWhenDlqQueueSetIsNull`/`...ThrowsNotFoundWhenDlqTopicMissingTest` drive the paths over mocked audit sinks. ### What Did You Expect to See? Every stored audit result is one of the three words the summary buckets and the api-spec declares, so `successful + failed + partial == total` for newly written rows, and the breakdown no longer loses them. The domain nuance stays visible without a fourth result word: the outbox's operation distinguishes a scheduled retry (`RETRY_ALERT_NOTIFICATION`) from an exhausted one (`FAIL_ALERT_NOTIFICATION`), the DLQ resend response keeps its documented `outcome` (`SUCCESS` / `PARTIAL` / `FAILED` / `NO_MESSAGES`) and its `dlqTopicMissing=true` detail marker, and the missing-topic path still answers `404`. ### What Did You See Instead? The audit result argument was `RETRYING`, `NOT_FOUND` or `NO_MESSAGES`, none of which any bucket claims — the rows exist in the log and in the total, and the breakdown silently omits them. ### Additional Context A fix with regression tests follows in a pull request. Rows already stored keep their values, matching #4657. ### 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]
