Frun1na opened a new issue, #6800: URL: https://github.com/apache/rocketmq-dashboard/issues/6800
### 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 unit tests against that commit ### Runtime Environment not applicable — the defect is in two date filters, reproduced with jsdom unit tests that drive the rendered pickers ### Connected RocketMQ Cluster not applicable — reproduced with a stubbed audit service in unit tests ### Describe the Bug Two date filters cannot apply a single boundary: 1. The audit page's filter bar (`web/src/pages/ops/audit.tsx:498`): `GET /api/audit-logs` takes `startDate` and `endDate` as independent optional parameters (`AuditController.queryLogs`) and `buildAuditFilters` already maps a single end (`audit.tsx:79-87`), but the `DatePicker.RangePicker` has no `allowEmpty`. Ant Design defaults `allowEmpty` to `[false, false]`, so the picker keeps the range pending until both ends are set and the single date never reaches the query. 2. The resource operation timeline modal (`web/src/pages/ops/ResourceOperationTimelineModal.tsx:174`): same picker, same missing prop; `buildTimelineFilter` also sends each boundary only when it is set (`:69-70`). So an operator cannot ask for "everything since 2026-08-01" on either surface, even though the endpoint and both filter builders support it. The sibling system alerts page was fixed in #6637 (`46e7fde4`) by adding `allowEmpty={[true, true]}`; the deliveries page has the same fix in #6792. ### Steps to Reproduce ``` cd web npx vitest run src/pages/ops/__tests__/AuditPage.test.tsx npx vitest run src/pages/ops/__tests__/ResourceOperationTimelineModal.test.tsx ``` Both new cases pick a single boundary in the rendered picker and assert the service receives it. On a92c2314 they fail with: ``` AssertionError: expected last "vi.fn()" call to have been called with [ ObjectContaining{…} ] ❯ src/pages/ops/__tests__/AuditPage.test.tsx:325:43 ``` ``` AssertionError: expected last "vi.fn()" call to have been called with [ { page: 1, pageSize: 20, …(4) } ] ❯ src/pages/ops/__tests__/ResourceOperationTimelineModal.test.tsx:254:43 ``` In a browser the same happens: click the start date, pick a day, click outside — the list is not filtered, and picking a second date is required before anything is applied. ### What Did You Expect to See? One picked day scopes the query from (or up to) that date, as the endpoint contract and the existing filter builders allow. ### What Did You See Instead? The picker requires both ends before it commits a value, so a one-sided date filter cannot be entered on either page. ### Additional Context A fix with regression tests 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]
