Anyeling0620 opened a new pull request, #6149:
URL: https://github.com/apache/rocketmq-dashboard/pull/6149
Fixes #6148
### Problem
On the **Message** page (same pattern on **DLQMessage** and **Dashboard**),
merely moving the
mouse over an open Begin/End date-time picker corrupts the filter state:
* the panel's year runs away: `2029 → 2031 → 2033 → … → 2065` over one
24-step mouse sweep
* the input ends up displaying a bogus time (`2026-10-10 00:00:00` →
`2042-11-30 00:00:00`) and
pressing `Esc` does not restore it
* clicking a cell selects a **different** date than the one clicked
* pressing **Search** afterwards is rejected by the page's own validation
with
*"end time should be later than begin time"* and no request is sent
Reproduced on the released image `apacherocketmq/rocketmq-dashboard:latest`
(digest
`sha256:ce78506bd6fe01095bf1b37c954625e363ba5afae5d1539b77f395785d445e33`, =
tag `2.1.0`),
Chromium 156 headless, locale `zh-CN`.
### How to reproduce
1. Message → Topic; click the **Begin** date-time field (value e.g.
`2026-10-10 00:00:00`)
2. Without clicking anything, move the mouse a few times across the open
panel
3. Watch the panel year run away; press `Esc` and look at the input value
4. Press **Search** → error toast, no request
### Screenshots (same instance, only the frontend bundle differs)
**Before** (official 2.1.0 image) — all 42 cells selected, panel = Feb 2029
for a 2026-10-10 value;
**After** (this PR) — 1 cell selected, panel = Oct 2026, hover no longer
drifts.
### Root cause
antd v5's `DatePicker` is dayjs-based, and its `generateConfig` helpers
**never clone** —
they are written for dayjs, which is immutable:
```js
setYear: (d, y) => d.year(y),
setMonth: (d, m) => d.month(m),
setDate: (d, x) => d.date(x),
setHour/setMinute/setSecond/setMillisecond: ...,
addYear: (d, n) => d.add(n, 'year'),
addMonth / addDate: ...,
getEndDate: (d) => d.endOf('month'),
locale.getWeekFirstDate / getWeek / format: ...
```
The pages above hand **Moment** objects to those pickers
(`useState(moment())`). Moment mutates
in place, so every internal rc-picker call (panel navigation, hover preview,
time-column hover)
rewrites the page's own state object **without firing `onChange`** — same
object reference, new
value. The picker then follows the object it was given, which is why the
year "runs away".
Instrumented proof on the shipped bundle (no source change): after hovering
only,
`state.begin` changed `2026-10-10 → 2042-11-30` while `onChange` was called
0 times and the
object identity stayed the same (`sameRef === true`); the subsequent search
was blocked by the
`END_TIME_EARLIER_THAN_BEGIN_TIME` check.
### Fix
Use dayjs (already a dependency) for the states bound to a `DatePicker`:
| file | change |
|---|---|
| `frontend-new/src/pages/Message/message.jsx` | picker states `moment()` →
`dayjs()` |
| `frontend-new/src/pages/DlqMessage/dlqmessage.jsx` | same, and drop the
`moment(x).valueOf()` wrappers around those two values |
| `frontend-new/src/pages/Dashboard/DashboardPage.jsx` | `date` state
`moment()` → `dayjs()` |
`moment` is kept where it is still used for formatting timestamps.
### Verification (A/B with the built bundle served against a live 2.1.0
instance)
```
before: hover → input 2042-11-30 (state mutated, onChange count 0)
Search → blocked by validation, 0 requests sent
after: hover → input unchanged, panel stays on the current month (2026)
Search → POST /message/queryMessagePageByTopic.query
{"begin":1791624214820,"end":1791627814821}
clicked cell 2026-10-13 → input becomes 2026-10-13 ✅
```
--
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]
