unbridled-41 opened a new issue, #5913: URL: https://github.com/apache/rocketmq-dashboard/issues/5913
### Studio Version branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is based on it) deployed as: the repository's own compose deployment (`deploy/docker-compose.yml`, `TZ=Asia/Shanghai`) ### Runtime Environment Reproduced with the backend unit tests (`cd server && mvn -o -B -ntp test -Dtest='NotificationOutboxServiceTest'`); the visible effect needs the database session zone to differ from UTC, which the documented deployment sets. ### Connected RocketMQ Cluster Not involved. The rows live in Studio's own `rmq_alert_notification_outbox` table. ### Describe the Bug Every instant of a delivery row is written from the service's UTC clock (`utcNow()` = `LocalDateTime.now(ZoneOffset.UTC)`: `next_attempt_at`, `sending_started_at`, `delivered_at`), the mapper ships `gmt_create` to the console as `createdAt`, the page renders it with `formatUtcDateTime`, and the retention cutoff is a UTC instant - but the two bookkeeping columns were left to the database: - `RmqAlertNotificationOutbox` has no `gmtCreate` field, and no update path names `gmt_modified`, so MySQL's `DEFAULT CURRENT_TIMESTAMP` / `ON UPDATE CURRENT_TIMESTAMP` filled both in the session's zone (`deploy/docker-compose.yml` sets `TZ=Asia/Shanghai` on the database and on the server). - `RmqAlertNotificationOutboxMapper.deleteTerminalBefore` compares `gmt_modified` against a UTC cutoff, and the delivery page's time filter sends UTC bounds against `gmt_create`. On the deployed system that shifts the Alert Deliveries page by the whole offset: "Created At" and the drawer print a time eight hours ahead (a row created three seconds before delivery can print a later time than its delivery), the time-range filter selects the wrong window, and terminal rows are retained eight hours longer than configured. ### Steps to Reproduce 1. Run the compose deployment (or any MySQL whose session zone is not UTC) and let an alert produce a notification. 2. Open Alert Deliveries: 创建时间 is shifted by the offset while 投递时间 of the same row is UTC. 3. Filter by a time range covering the real creation instant: the row is not returned. ### What Did You Expect to See? Both bookkeeping columns hold the same UTC instant family as the rest of the row. ### What Did You See Instead? Values written by the database in the server's local zone, read back as if they were UTC. ### Evidence - `server/.../ops/alert/NotificationOutboxService.java` (`enqueue` and the four update paths, `utcNow()`), `server/.../persistence/entity/RmqAlertNotificationOutbox.java`, `server/.../persistence/mapper/RmqAlertNotificationOutboxMapper.java:28-29,41,49,56,66-67`, `server/src/main/resources/db/schema.sql:402-403`, `web/src/pages/ops/notificationDeliveries.tsx`. - `cd server && mvn -o -B -ntp test -Dtest='NotificationOutboxServiceTest#enqueueStampsBothBookkeepingColumnsInUtcTest+retryingAFailedDeliveryStampsTheModifiedInstantTest'` - both fail before the fix with the JVM zone set to Asia/Shanghai. ### Impact The delivery audit surface shows wrong times and filters by the wrong window, and the configured notification retention is off by the server offset. ### Acceptance Criteria - Both bookkeeping columns are stamped from the same UTC clock on insert and on every update path, with regression tests that pin the zone. **Corresponding PR:** #ISSUEPR# -- 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]
