unbridled-41 opened a new pull request, #4564:
URL: https://github.com/apache/rocketmq-dashboard/pull/4564
Fixes #4563.
## Problem / Evidence
The server query history drawer stores its applied search keyword and page
in component state, but its `<Input.Search>` is uncontrolled and the drawer
content is destroyed on close (`destroyOnHidden`). Reopening shows an **empty
search input** while both tables stay filtered by the keyword submitted before
the drawer was closed — the operator sees a filtered history with no visible
filter.
Reproduction (master `d50ffecc`): open the drawer → type `order-1` → press
Enter → close → reopen. The input renders empty; the message/trace tables are
still filtered by `order-1` (`listMessageQueryHistory` keeps receiving `search:
'order-1'`). This is the defect reported in #2474 (bot-confirmed, closed stale
without an implementation); #2478 (closed unmerged) proposed the same
controlled-draft direction.
## Root cause / Fix
The input's DOM is recreated empty by `destroyOnHidden` while the `search`
state that drives the API calls survives in the always-mounted component.
Fix (`web/src/components/MessageQueryHistoryDrawer.tsx`, +18/−0): drive the
input from a new `searchDraft` state. On submit (`onSearch`) the draft is
trimmed into the applied `search` (and page resets to 1); when the drawer
opens, a render-time state adjustment (the same pattern the alerts page uses
for its domain switch) restores `searchDraft` from the applied `search`, so the
visible input always matches the filter actually applied to the tables.
Clearing the field and submitting applies an empty filter. `load`/request-guard
behavior is unchanged.
## Priority & scoring
PRIORITY 76 = impact 30 (server query history is a core message-triage flow;
a hidden filter hides rows and misleads incident review) + scope 10 (single
drawer component) + reproducibility 20 (deterministic, every reopen after a
search) + maintenance value 16 (aligns the drawer with the repo's
committed-query pattern; prior confirmed-but-unfixed issue). FIX_CONFIDENCE 95:
state-only change, fully covered by two new deterministic regression tests, no
API change.
## Tests
- `npx vitest run
src/components/__tests__/MessageQueryHistoryDrawer.test.tsx`
- Red (master + new tests): `keeps the applied search visible...` failed —
reopened input had value `''` while `order-1` was expected; `applies a cleared
search field as an empty filter` failed before the fix's controlled input
(allowClear cleared the DOM but not the applied filter).
- Green: **6/6 passed**.
- Full web suite on this branch (clean run, no concurrent load): **1036
tests (1034 pristine + 2 new), 6 failed** — all 6 in the pre-existing
load-flaky family (`ClusterPage` ×1, `ConsumerPage` ×3, `TopicPage` ×2
timeouts/act warnings); none touch the drawer. Pristine master measured the
same 1034-test suite with the same rotating failure set.
- `npx tsc -b` clean; `npx eslint` on both changed files clean; `npm run
build` ✓ (12.3s).
## Risk
Low. State-only change inside one component; no API contract change. The
only behavior delta beyond the fix is that the input no longer diverges from
the applied filter after reopen; typing without submitting still does not
trigger requests (unchanged).
Upstream CI note: the repository's CI workflow fails at startup for every
branch and PR (infrastructure-level, seen on maintainer branches too), so local
verification above substitutes for it.
--
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]
