unbridled-41 opened a new issue, #4653:
URL: https://github.com/apache/rocketmq-dashboard/issues/4653
### Studio Version
branch: `master`
git commit id: `d50ffecc9d7e8f8f46da64198831bd7952e6974e`
deployed as: built from source (dev profile)
### Runtime Environment
Ubuntu (WSL2), JDK Temurin 21, Maven 3.9 (offline repo), dev H2 profile for
tests.
### Connected RocketMQ Cluster
Not required — the defect is in Studio's notification-delivery audit
recording.
### Describe the Bug
When an alert-notification delivery exhausts its retry attempts
(`NotificationOutboxService.MAX_ATTEMPTS = 5`), the operation-audit row is
written with result `"FAILURE"` (`NotificationOutboxService.java:519-521`):
```java
recordDeliverySafely(row, exhausted ? "FAIL_ALERT_NOTIFICATION" :
"RETRY_ALERT_NOTIFICATION",
exhausted ? "FAILURE" : "RETRYING", abbreviate(error));
```
The audit result vocabulary used everywhere else in the server is `SUCCESS`
/ `FAILED` / `PARTIAL` (`OperationAuditConstants.Result`,
`MybatisPlusAuditRepository.summarize` buckets only
`SUCCESS`/`FAILED`/`PARTIAL`, DLQ resend classifies into
`SUCCESS`/`FAILED`/`PARTIAL`/`NO_MESSAGES`, direct-consume audits write
`FAILED`).
Consequences:
1. `MybatisPlusAuditRepository.summarize`
(`MybatisPlusAuditRepository.java:124-133`) builds
`successful`/`failed`/`partial` buckets with
`getOrDefault("SUCCESS"/"FAILED"/"PARTIAL", 0L)`. A `FAILURE` row is counted in
`total` but lands in none of the three buckets, so the audit summary cards
never add up to the total and the failed count permanently misses
notification-delivery failures.
2. The web audit page derives its result filter options from the distinct
`result` values in the data (`filterOptions.results`), so the list shows two
visually identical "Failed" entries (`FAILED` and `FAILURE`) that select
different row sets.
### Steps to Reproduce
1. Configure a DingTalk webhook that always rejects (or none at all) so
dispatch fails.
2. Let an alert notification exhaust 5 retry attempts (row status `FAILED`).
3. Open the Ops → Audit page: `IMPORT`… the row appears as
`FAIL_ALERT_NOTIFICATION` / `FAILURE`.
4. The summary cards show `total ≥ 1`, `failed = 0`.
A focused Mockito regression on unmodified `master` verifies `record(...,
"FAILURE", ...)` today: the audit vocabulary assertion fails with `expected
"FAILED" but was "FAILURE"`.
### What Did You Expect to See?
The exhausted-delivery audit row uses the shared `FAILED` result vocabulary,
so it lands in the audit summary's failed bucket and the web filter offers one
"Failed" option.
### What Did You See Instead?
The row is recorded as `FAILURE`, is invisible to the failed summary bucket,
and duplicates the "Failed" filter entry.
### Additional Context
The one-off `"RETRYING"` result for non-exhausted retries has the same
vocabulary-mismatch shape (it only shows up as an unknown filter value), but
the deterministic bucketing loss is the `FAILURE` value. The fix should keep
`RETRYING` semantics intact or align both with the shared vocabulary; the
summary/filter behavior is the observable defect.
AI-assisted source audit; the fail-before test was executed locally on Java
21.
--
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]
