unbridled-41 opened a new issue, #5903:
URL: https://github.com/apache/rocketmq-dashboard/issues/5903
### 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='MybatisPlusK8sCertRepositoryTest'`); the effect needs the JVM default
zone to differ from UTC, which the documented deployment sets.
### Connected RocketMQ Cluster
Not involved. The rows live in Studio's own `rmq_k8s_certificate` table.
### Describe the Bug
`K8sCertService` stamps both certificate instants from its UTC clock and
documents the contract ("Serialize certificate instants as UTC wall time: the
frontend (formatUtcDateTime) interprets the zoneless wire value as UTC"), but
the repository overwrites one of them on the way to the database:
```java
// server/.../cluster/k8s/MybatisPlusK8sCertRepository.java (before)
entity.setGmtCreate(cert.getGmtCreate()); // the service's UTC instant
entity.setGmtModified(LocalDateTime.now()); // the JVM default zone
```
The create response is built from the in-memory VO, so it reports UTC; the
next `GET /api/k8s-certs` reads the row back and reports the same field shifted
by the whole server offset - disagreeing with `gmt_create` of its own row. Same
defect class as the merged certificate instant fix (#5197) and the auth-table
fix.
### Steps to Reproduce
1. Run with `TZ=Asia/Shanghai` (the compose default) and create a
certificate.
2. Compare the `gmtModified` of the create response with the value `GET
/api/k8s-certs` returns for the same row.
3. Measured in the unit test with the default zone set: `expected
2026-10-09T16:17 (UTC instant) but was 2026-10-10T01:17` (offset applied).
### What Did You Expect to See?
The persisted modified instant is the one the service stamped, like
`gmt_create`.
### What Did You See Instead?
The repository re-stamped it from the JVM default zone.
### Evidence
- `server/.../cluster/k8s/MybatisPlusK8sCertRepository.java` (`toEntity`),
`server/.../cluster/k8s/K8sCertService.java:64,78,149`
(`LocalDateTime.now(clock)`, `Clock.systemUTC()`).
- `cd server && mvn -o -B -ntp test
-Dtest='MybatisPlusK8sCertRepositoryTest#saveShouldPersistTheUtcModifiedInstantTheServiceStampedTest'`
- fails before the fix, passes after.
### Impact
`gmtModified` is reported hours in the future for API consumers on any
deployment whose server zone is not UTC, and disagrees with the same row's
`gmt_create`.
### Acceptance Criteria
- The repository persists the instant the service stamped and only falls
back to a UTC clock when the VO carries none, with a regression test that pins
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]
