unbridled-41 opened a new issue, #4964: URL: https://github.com/apache/rocketmq-dashboard/issues/4964
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. Searched for `notification delivery created at`, `deliveries timestamp`, `outbox retention`, `gmt_modified CURRENT_TIMESTAMP`, `bookkeeping column timezone` and `投递记录 时间`. The nearest are #2748 (closed: bounded retention cleanup, a performance change) and the sibling surface below — neither covers this table's write path. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version branch: `rocketmq-studio` git commit id: `1ef5d860` (the revision this was written against; the fix is in PR #4949, branched from that commit) deployed as: not required for the reproduction — see Runtime Environment. The deployment detail that matters is in "Additional Context". ### Runtime Environment Reproduced with the backend unit tests (`cd server && mvn -o test -Dtest=NotificationOutboxServiceTest`), which need no MySQL and no cluster. The live effect depends on one deployment fact that is checked in to this repository, quoted under Additional Context. ### Connected RocketMQ Cluster Not involved. The rows live in Studio's own `rmq_alert_notification_outbox` table. ### Describe the Bug The two bookkeeping columns of `rmq_alert_notification_outbox` are written by the database's clock, while every other timestamp of the same row is written by the application in UTC — and the console renders them as UTC. * `server/src/main/resources/db/schema.sql:375-376` declares `` `gmt_create` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP `` and `` `gmt_modified` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ``. * The entity has no `gmtCreate` property at all (`RmqAlertNotificationOutbox.java:24-30`), so MyBatis-Plus's `insert` cannot write the column: the default is the only writer. * Every state timestamp of that row comes from `utcNow()` instead — `next_attempt_at` (`NotificationOutboxService.java:192`), `delivered_at` (`:367`), `sending_started_at` (`:296`) — and the cleanup cutoff is `utcNow().minus(retention)` (`:321`). * The console renders `createdAt` as UTC: `web/src/pages/ops/notificationDeliveries.tsx:212` is `formatUtcDateTime(record.deliveredAt ?? record.createdAt)` and `:348` is the drawer's "Created At"; `web/src/utils/format.ts:49-58` appends `Z` to an offset-less string. A PENDING row has no `deliveredAt`, so its creation time is what the page shows. Two visible consequences: 1. On a database whose session time zone is not UTC, the shown creation time of a delivery is offset from the other timestamps of its own row. 2. The retention sweep compares the UTC cutoff against `gmt_modified` (`RmqAlertNotificationOutboxMapper.java:28-29`), so a terminal delivery is kept for the configured retention *plus or minus* the database's offset. ### Steps to Reproduce 1. `cd server && mvn -o test -Dtest='NotificationOutboxServiceTest#mutationsShouldStampGmtModifiedInsteadOfLeavingItToTheColumnDefaultTest'` on `1ef5d860`. 2. The test drives a state write through the service and inspects the `UpdateWrapper` that reaches the mapper. 3. The run fails: the set clause is `status=…,attempt_count=…,next_attempt_at=…,sending_started_at=…,claim_token=…,last_error=…` with no `gmt_modified`, so the column is left to `ON UPDATE CURRENT_TIMESTAMP`. The insert half is visible in the same test class: `enqueueShouldStampBothBookkeepingColumnsInUtcTest` cannot even compile against `1ef5d860` (`cannot find symbol: method getGmtCreate()`), which is the direct evidence that no Java code writes `gmt_create` for this table. Live observation: with a MySQL session zone that is not UTC, `SELECT gmt_create, next_attempt_at, delivered_at FROM rmq_alert_notification_outbox` shows `gmt_create` offset from the UTC columns of the same row, and the Ops → Notification Deliveries page shows a PENDING row's creation time shifted by the same offset. ### What Did You Expect to See? One row, one clock: the bookkeeping columns hold UTC like the rest of the table, so the deliveries page shows the creation time it actually happened at, and the retention sweep measures the configured window against the same clock it uses for its cutoff. ### What Did You See Instead? `gmt_create`/`gmt_modified` come from the MySQL session's clock while the row's other timestamps are UTC, so the deliveries page and the retention sweep each mix two time bases. ### Additional Context **The deployment that makes this live.** `deploy/docker-compose.yml:13` sets the MySQL container `TZ: ${TZ:-Asia/Shanghai}` and `:86` points the application at it with `serverTimezone=Asia/Shanghai`, so `CURRENT_TIMESTAMP` is evaluated in a zone that is not UTC. This is a checked-in fact about the shipped compose file, not a report about a particular installation. **Sibling surfaces, tracked separately.** The same mix exists on two other tables, and `rmq_studio_session.gmt_create` / `rmq_studio_user.gmt_create`+`gmt_modified` are rendered as UTC too. That user-facing half is tracked by #4234, whose review of #4235 held the client-side change precisely because this write path was open; PR #4949 settles it as well and carries `Fixes #4234`. **Boundary.** This issue does not ask for a schema change: the defaults can stay as a fallback for rows written outside the application. It asks that the application write these columns from the clock that already writes the rest of the row. Corresponding pull request: #4949 (`fix(studio): write the bookkeeping columns from the UTC clock the rest of the row uses`). ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
