tju-yxq opened a new issue, #6156:
URL: https://github.com/apache/rocketmq-dashboard/issues/6156
> Resubmission of #5396 — the original report was closed by the repo's 7-day
stale bot for inactivity, not because it was fixed or rejected; the problem is
still reproducible on the current `rocketmq-studio` head. An updated PR
carrying the fix is being filed against this report.
## Problem
The notification deliveries table's **"Delivered At" column lies for every
record that was never delivered.** The column renders
`formatUtcDateTime(record.deliveredAt ?? record.createdAt)`, so a FAILED,
PENDING, SENDING or RETRY_WAIT record shows its **creation** timestamp under
the "投递时间 / Delivered At" header — a webhook send that was rejected on the
first attempt looks like it was delivered at the exact moment it was queued. An
operator scanning the feed for "did anything actually go out?" gets a wrong
answer from the table, then opens the detail drawer for the same record and
sees `-` — the page contradicts itself.
## What did you do (steps to reproduce)?
1. Trigger a notification that fails to deliver (e.g., a DingTalk webhook
that rejects the request) and leave it in FAILED state.
2. Open **Ops > Notification Deliveries**.
3. The row shows the failure in the result column, but the "投递时间" column
shows the record's creation time as if it had been delivered.
4. Open the row's detail drawer: the "投递时间" field correctly shows `-` while
"创建时间" shows the timestamp the table just presented as the delivery time.
## What did you expect to see?
The column renders the `deliveredAt` field and shows `-` for records without
one, exactly like the drawer.
## What did you see instead?
The creation time masquerading as the delivery time for every undelivered
record.
## Root cause
`web/src/pages/ops/notificationDeliveries.tsx` line 222 (the table column):
```tsx
render: (_, record) => formatUtcDateTime(record.deliveredAt ??
record.createdAt),
```
The detail drawer for the same record (lines 392-393) has no fallback:
```tsx
<Descriptions.Item label={t('deliveries.deliveredAt')}>
{formatUtcDateTime(selectedDelivery.deliveredAt)} // null renders '-'
</Descriptions.Item>
```
And the page's own result column (lines 206-217) distinguishes 已投递
(delivered) from 下次重试 (next retry) — the page's model says an undelivered
record has no delivery time. `formatUtcDateTime` already returns `'-'` for
null, so the `?? record.createdAt` fallback is both unnecessary and wrong.
## Expected behavior
- The "Delivered At" column renders `deliveredAt` alone; undelivered records
show `-`.
- Delivered records show their actual delivery timestamp (unchanged).
- The drawer, filters, retry actions and every other column are unchanged.
## Acceptance criteria
- [ ] Regression proof: on the current code, a FAILED record's Delivered At
cell shows the formatted `createdAt`; with the fix it shows `-`.
- [ ] A DELIVERED record's cell still shows the formatted `deliveredAt`.
- [ ] The drawer's two timestamp fields are unchanged.
- [ ] All existing deliveries-page tests stay green.
## Environment
Branch `rocketmq-studio` at `6a68042f`; file:
`web/src/pages/ops/notificationDeliveries.tsx`.
## Duplicate check
Searched open and closed issues for `delivered at` and `delivery column`;
the only adjacent item is #4964 (delivery bookkeeping timestamps written by the
MySQL clock — a different, closed bug about timestamp sources). Nothing covers
the creation-time substitution.
--
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]
