tju-yxq opened a new issue, #5394:
URL: https://github.com/apache/rocketmq-dashboard/issues/5394
## Problem
On any deployment upgraded from a build before alert domains existed, the
paged alert feed silently **loses every pre-upgrade alert event** as soon as
the BUSINESS domain filter is applied — while the non-paged feed for the same
filter still returns them. The two alert endpoints disagree about the same
data, and the "related business alerts" lookup for a cluster incident misses
the same legacy rows.
## What did you do (steps to reproduce)?
1. Deploy a Studio version from before the alert-domain feature, let it
record alert events (all rows have `domain = NULL` — the column did not exist),
then upgrade to the current trunk. `AlertSchemaMigration` adds
`rmq_system_alert.domain` as a plain nullable `VARCHAR(16)` with **no default
and no backfill** (line 93), so the legacy rows keep `domain = NULL`.
2. Open **Ops > System Alerts** (the paged feed, `GET
/api/system-alerts/page?domain=BUSINESS`): the pre-upgrade events are missing.
3. Call the non-paged feed with the same filter (`GET
/api/system-alerts?domain=BUSINESS`, the legacy list endpoint): the events are
there.
## What did you expect to see?
Both feeds apply the same domain filter to the same rows and agree.
## What did you see instead?
The paged feed drops every NULL-domain (legacy) row when filtering BUSINESS;
the non-paged feed includes them.
## Root cause
`server/src/main/java/org/apache/rocketmq/studio/ops/alert/MybatisPlusAlertRepository.java`,
`findAlertsPage` line 264:
```java
.eq(query.domain() != null, "domain", query.domain() == null ? null :
query.domain().name())
```
A plain equality never matches `domain = NULL`. Three facts in the same
module prove NULL means BUSINESS and must be matched:
1. `findRulesPage` (lines 100-105) handles exactly this case for rules, with
the comment "Rules created before alert domains were introduced are business
rules": `conditions.and(wrapper -> wrapper.isNull("domain").or().eq("domain",
AlertDomain.BUSINESS.name()));` — pinned by
`MybatisPlusAlertRepositoryTest.findRulesPageShouldIncludeLegacyBusinessRulesAndApplyFiltersTest`.
2. `parseDomain` (line 360) reads NULL/blank as `AlertDomain.BUSINESS`, and
`toAlertVO` uses it — the read model's convention is that NULL-domain events
ARE business events.
3. `AlertService.listAlerts(level, domain, ...)` (line 503) filters in
memory after the parseDomain default, so the non-paged feed includes the legacy
rows.
The contrast with the migration is deliberate on the rule side only:
`rmq_alert_rule.domain` is added as `NOT NULL DEFAULT 'BUSINESS'` (backfilled),
while `rmq_system_alert.domain` is left nullable — the alert-event side was
simply never given the NULL-tolerant filter. `findRelatedAlerts` (AlertService
line 560) builds its window query through `findAlertsPage` with the related
domain, so it inherits the same miss.
## Expected behavior
- Filtering the paged feed (and `findRelatedAlerts`) by BUSINESS matches
`domain IS NULL OR domain = 'BUSINESS'`, mirroring `findRulesPage`.
- Filtering by CLUSTER (or any other domain) keeps the exact equality.
- Sorting (`ORDER BY time DESC,id DESC`) and every other filter are
unchanged.
## Acceptance criteria
- [ ] Regression proof: on the current code, `findAlertsPage` with
`domain=BUSINESS` produces a plain `domain =` condition (NULL rows unmatched);
with the fix it produces `domain IS NULL OR domain =` and binds `BUSINESS`.
- [ ] `findAlertsPage` with `domain=CLUSTER` still uses the exact equality
with no `IS NULL`.
- [ ] The non-paged `listAlerts` behavior is unchanged.
- [ ] Existing rule-side legacy handling and all other repository tests stay
green.
## Environment
Branch `rocketmq-studio` at `6a68042f`; files:
`MybatisPlusAlertRepository.java`, `AlertSchemaMigration.java`,
`AlertService.java`.
## Duplicate check
Searched open and closed issues for `alert domain filter` and `legacy alerts
missing`; nothing covers the NULL-domain alert-event miss (the domain feature
work and its fixes do not mention the paged feed dropping pre-migration rows).
--
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]
