iloveeyjafjalla opened a new issue, #7238: URL: https://github.com/apache/rocketmq-dashboard/issues/7238
## Summary The ACL mutation tools return the **server-local** creation stamp the service keeps for form prefill, while every other ACL output (REST reads, `rmq.acl.get`, `rmq.acl.list`) returns the UTC wire value. In a UTC+8 JVM, `rmq.acl.create`/`rmq.acl.update` therefore report a `gmtCreate` eight hours ahead of the identical row read back through `rmq.acl.get` — and the console puts that echo straight into its table row, so the 创建时间 cell jumps by the offset until the next reload. ## Why - `AclService.createRule`/`updateRule` return the stored row unchanged (`server/src/main/java/org/apache/rocketmq/studio/instance/acl/AclService.java:135-139`, `:176-180`), with a comment stating the write echo is the server-local base for form prefill; the read paths convert with `toUtcWire` (`:101-120`, `:142-155`, `:786-820`), which is also what #6686 made explicit for the ACL wire contract. - The two mutation tool handlers returned that echo verbatim as the tool result (`.../tool/handler/acl/AclCreateToolHandler.java:58-60`, `.../AclUpdateToolHandler.java:65-69`), unlike every other ACL tool output. - The console patches the edited row with the update response (`web/src/pages/instance/acl.tsx:493`, `:543`) and parses timestamps as UTC, so the cell shifts by the server offset. ## Reproduction `AclCreateToolHandlerTest` → `executeShouldReturnTheUtcWireStampOtherToolOutputsUseTest`, with the JVM in `Asia/Shanghai` and the mocked service echoing `LocalDateTime.now()`: ``` Expecting actual: 2026-10-20T19:5x (the server-local echo) to be close to ... 11:5x (the UTC wire instant) ``` ## Expected The mutation tools answer on the same clock as the read tools: the stored server-local instant converted to the UTC wire, with the service's form-prefill echo unchanged. -- 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]
