Frun1na opened a new issue, #6791: URL: https://github.com/apache/rocketmq-dashboard/issues/6791
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `rocketmq-studio` branch, or I have stated the exact version I am running below. ### Studio Version branch: rocketmq-studio git commit id: a92c23144408cdf5729707050e9ecd9b75f1bad0 deployed as: reproduced by a unit test against that commit ### Runtime Environment not applicable — the defect is in the deliveries filter bar, reproduced with a jsdom unit test that drives the rendered picker ### Connected RocketMQ Cluster not applicable — reproduced with a stubbed deliveries service in a unit test ### Describe the Bug The notification deliveries page cannot filter by only one end of the time range. `GET /api/system-alerts/deliveries/page` takes `from` and `to` as two independent optional parameters (`SystemAlertController.listDeliveriesPage`, `server/src/main/java/org/apache/rocketmq/studio/ops/alert/SystemAlertController.java:82-98`), and the page's own filter state is typed `{from?: string; to?: string}` (`web/src/pages/ops/notificationDeliveries.tsx:61`). The control, however, only ever produces a complete pair: the `DatePicker.RangePicker` at line 333 has no `allowEmpty`, and Ant Design's picker defaults `allowEmpty` to `[false, false]`, so a one-sided value cannot be confirmed (with `showTime` the OK button stays disabled until both ends are set). On top of that the `onChange` at line 339 writes the filter only when `dates?.[0] && dates[1]` and otherwise assigns `{}`, which clears whatever range was applied. The result: an operator asking "everything since yesterday" cannot express it — the picker refuses the single boundary, and the request that follows either keeps the previous range or drops the filter entirely. The sibling page was fixed hours earlier in #6637 (`46e7fde4`, "restore open-ended event time filters"): the system alerts page got `allowEmpty={[true, true]}` and maps a single boundary to `{from: X, to: undefined}` (`web/src/pages/ops/systemAlerts.tsx:627`). ### Steps to Reproduce ``` cd web && npx vitest run src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx ``` Open the deliveries page, click the "投递开始时间" field, pick one day in the calendar and confirm it with OK: the picker cannot commit a one-sided range, and the list is not filtered from that day on. The new unit test does exactly this and asserts the request carries `from` with no `to`; on a92c2314 it fails with: ``` AssertionError: expected last "vi.fn()" call to have been called with [ ObjectContaining{…} ] ❯ src/pages/ops/__tests__/NotificationDeliveriesPage.test.tsx:207:39 ``` ### What Did You Expect to See? A single picked boundary narrows the feed: everything after that instant (or up to it), matching the endpoint's contract and the page's own `{from?, to?}` filter state. ### What Did You See Instead? The picker requires both ends (`allowEmpty` defaults to false) and the handler drops a partial range, so a one-sided filter either cannot be entered or is silently discarded. ### Additional Context A fix with a regression test follows in a pull request. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
