iloveeyjafjalla opened a new issue, #6868:
URL: https://github.com/apache/rocketmq-dashboard/issues/6868
## Summary
The message dialog's 验证 tab prints `1970-01-01 08:00:00.000` as the 消费时间 of
a group that has **no consumption record**, and the trace step time prints the
same instant for a node whose SubAfter record carried no timestamp.
## Why
- Both endpoints report "no time" as `0`, and the API documents it:
`docs/api-spec.md:1610` — `consumeTime | number | 消费时间（Unix 毫秒时间戳；无时间时为 0）`.
`ConsumerStatusVO.consumeTime` is a primitive `long` (`:32`), the Aliyun
converter writes `parseTimeMillis(operateTime)` (`AliyunConverters.java:324`,
`:397`), and the Apache path reads the optional 8th SubAfter column
(`RocketMQMessageProvider.java:917` — `parseLong(field(f, 7))`), so a missing
value always arrives as `0`.
- The page used to handle that: the formatter it owned began with `if
(!value) return '-'`, the guard #2094 added for bug #2081. #4829 ("share one
message timestamp formatter", `7d25628d`) replaced it with the shared
`formatTimeMs`, whose opposite behaviour on purpose is pinned by
`format.test.ts` ("preserves the Unix epoch timestamp") because it also formats
real stored epochs.
- What is left at the call site recognises only the *string* `'-'`
(`web/src/pages/instance/message.tsx:983-988`) — the value the demo fixture
sends and no real backend ever does.
- The same dialog already treats `0` as missing elsewhere:
`web/src/utils/messageTraceDiagnostics.ts` raises `INVALID_CONSUME_TIME` and
`INVALID_TRACE_TIMESTAMP` for exactly this value.
## Impact
On an Aliyun instance, or on an Apache cluster whose consumers reported a
legacy SubAfter record, the 验证 tab claims a consumption happened at the Unix
epoch — in the same dialog whose diagnostics panel labels that value invalid.
The trace step line repeats it for the node.
## Reproduction
`web/src/pages/instance/__tests__/MessagePage.test.tsx` → `renders a
consumption with no recorded time as the placeholder instead of the Unix epoch`
opens the dialog with `consumerStatus: [{ group: 'cg-orders', deliveryStatus:
'pending', consumeTime: 0, retryCount: 0 }]`:
```
expect(within(statusRow).getAllByRole('cell')[2]).toHaveTextContent('-')
1970-01-01 08:00:00.000
```
## Expected
Both call sites render the placeholder for `0`, as the page did before the
formatter was shared, while `formatTimeMs` keeps rendering a real epoch for a
stored timestamp.
--
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]
