zjncs opened a new pull request, #3995:
URL: https://github.com/apache/rocketmq-dashboard/pull/3995
### Motivation
The dashboard's alert subsystem deliberately stores **zone-less UTC
`LocalDateTime` values** (`AlertService` stamps
`LocalDateTime.now(ZoneOffset.UTC)`, e.g. `acknowledgedAt`) and the web layer
renders them with `formatUtcDateTime`, whose doc comment spells out the
contract: *"Alert APIs serialize UTC LocalDateTime values without an offset, so
normal Date parsing would incorrectly treat them as browser-local timestamps."*
(`web/src/utils/format.ts`)
The audit subsystem breaks that same contract in both directions:
- **Writers stamp `LocalDateTime.now()`** in the server's default zone
(`OperationAuditService.record`, `AuditService.record`, and the
`MybatisPlusAuditRepository.save` fallback). On a server running anything other
than UTC, the audit row for e.g. *acknowledge alert* shows a wall-clock time
that differs from the UTC `acknowledgedAt` the alert subsystem writes for the
very same action, so cross-referencing the two views is inconsistent.
- **The audit page renders those zone-less values with `formatDateTime`**,
which parses them as **browser-local**. Every audit timestamp is therefore
shifted by the viewer's UTC offset (e.g. a viewer in UTC+8 sees times 8 hours
in the future).
### Modification
Align the audit subsystem with the UTC contract:
- Stamp `LocalDateTime.now(ZoneOffset.UTC)` at the three write sites:
- `OperationAuditService.record` (gmtCreate/gmtModified)
- `AuditService.record` (record timestamp)
- `MybatisPlusAuditRepository.save` (fallback when the record carries no
timestamp)
- Compute the `cleanupLogs` cutoff in UTC so it is comparable with the
stored `gmt_create` values (which are now UTC).
- Render the audit timestamp column with `formatUtcDateTime`
(`web/src/pages/ops/audit.tsx`), displaying it in the viewer's timezone with an
explicit zone suffix — the same presentation the notification-delivery and
system-alert pages already use.
### Verification
Fail-before / pass-after regression tests, all forcing the server zone to
`Asia/Shanghai` so the buggy system-zone `now()` is 8 hours off regardless of
the host zone:
Backend (`mvn test`):
-
`OperationAuditServiceTest#recordShouldStampUtcTimestampsRegardlessOfServerZone`
— was +8h, now matches UTC
- `AuditServiceTest#recordShouldStampUtcTimestampRegardlessOfServerZoneTest`
— was +8h, now matches UTC
- `AuditServiceTest#cleanupLogsShouldCutOffInUtcRegardlessOfServerZoneTest`
— cutoff was +8h, now matches UTC
-
`MybatisPlusAuditRepositoryTest#saveShouldStampUtcWhenTimestampMissingRegardlessOfServerZoneTest`
— was +8h, now matches UTC
```
Tests run: 41, Failures: 0, Errors: 0 -- in OperationAuditServiceTest,
AuditServiceTest,
MybatisPlusAuditRepositoryTest, AuditControllerTest
```
Frontend (`vitest run src/pages/ops/__tests__/AuditPage.test.tsx`, verified
under both `TZ=Asia/Shanghai` and `TZ=UTC`):
- new `renders the audit timestamp as UTC in the viewer timezone` plus an
assertion added to the existing presentation test — with the old
`formatDateTime` the rendered cell misses the expected UTC-converted text; all
9 tests pass with the fix
Known follow-up (out of scope): the day-granularity `startDate`/`endDate`
filters are compared against the UTC-stored `gmt_create`, so day boundaries can
skew by the viewer's offset; converting the picked local dates to a UTC range
before sending would be a separate UX decision.
--
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]
