yyqdbngt opened a new pull request, #4676:
URL: https://github.com/apache/rocketmq-dashboard/pull/4676
<!-- Base branch: `rocketmq-studio`, the RocketMQ Studio trunk. -->
### Which Issue(s) This PR Fixes
- No open issue tracks this exact defect. #4174 (fixed by #4175) covered
rendering the same
`lastTriggered` value as UTC; #3556 tracks the wider "page-local vs
result-set-wide counter"
question, which is about scope and needs a summary endpoint, not about
timestamp parsing.
### Brief Description
`web/src/pages/ops/alerts.tsx:417` computes the `本页 24h 触发` header counter
by comparing
`new Date(r.lastTriggered).getTime()` against `Date.now() - 24h`. The
backend stamps
`lastTriggered` with `ZoneOffset.UTC` and serializes it without an offset
suffix, so the bare
`new Date()` reads the value as browser-local time and shifts the instant by
the browser's offset.
At UTC+8 a rule that fired 20 hours ago is read as 28 hours ago and silently
drops out of the
counter, while the same value is rendered correctly through
`formatUtcDateTime` in the
`Last triggered` column of the very same table.
The comparison now anchors an offset-less value to UTC, the contract
`formatUtcDateTime`
documents, so the counter and the column agree.
### How Did You Test This Change?
New case in `web/src/pages/ops/__tests__/AlertsPage.test.tsx`: with
`TZ=Asia/Shanghai`,
`Date.now()` stubbed to `2026-08-23T12:00Z`, the page is served one rule
whose offset-less
`lastTriggered` is 20 hours old and the header must read `本页 24h 触发1`.
Red - on the unmodified base (new test copied in, `alerts.tsx` untouched):
```
$ cd web && npx vitest run src/pages/ops/__tests__/AlertsPage.test.tsx
❯ src/pages/ops/__tests__/AlertsPage.test.tsx (27 tests | 1 failed | 26
skipped) 6173ms
× counts a rule triggered in the last 24 hours by UTC, not
browser-local, time 6169ms
FAIL src/pages/ops/__tests__/AlertsPage.test.tsx > AlertsPage > counts a
rule triggered in the last 24 hours by UTC, not browser-local, time
AssertionError: expected '本页 24h 触发0' to be '本页 24h 触发1' // Object.is
equality
Expected: "本页 24h 触发1"
Test Files 1 failed (1)
Tests 1 failed | 26 skipped (27)
```
Green - with the fix:
```
$ cd web && npx vitest run src/pages/ops/__tests__/AlertsPage.test.tsx
Test Files 1 passed (1)
Tests 27 passed (27)
Duration 61.28s
```
The full `src/pages src/layouts` suite is green on this base (`54 passed
(54)`, `642 passed (642)`),
so the 26 other cases of this file are unchanged by the fix.
```
$ cd web && npx tsc -b # exit 0, no output
$ cd web && npx eslint src/pages/ops/alerts.tsx
src/pages/ops/__tests__/AlertsPage.test.tsx
✖ 5 problems (0 errors, 5 warnings)
```
All five warnings are pre-existing on the base file
(`react-refresh/only-export-components` at
`alerts.tsx:122,125`, `react-hooks/exhaustive-deps` at `alerts.tsx:407`, two
unused-variable
notices at `alerts.tsx:516`); the new test and the new helper add none. The
assertion is on the
rendered counter text on purpose - asserting `new
Date(value).toLocaleString()` would pass in any
zone because it reproduces the buggy parse.
The open PR #4480 (based on `master`) moves this counter to a server-side
summary but keeps
`new Date(rule.lastTriggered)` as its fallback, so this fix stays correct
with or without it.
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`feat:` / `fix:` /
`refactor:` / `chore:` / `docs:` / `perf:`)
- [x] Tests added or updated for non-trivial changes, test methods named
`...Test`
- [x] New UI text has both Chinese and English entries under `web/src/i18n/`
(no UI text is added)
- [x] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks); no server file is touched, so the Java suite is not affected
- [x] New source files carry the ASF license header (no new source file)
- [x] Documentation touched where behaviour changed (no README / `docs/`
page documents this counter)
--
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]
