unbridled-41 opened a new pull request, #4005:
URL: https://github.com/apache/rocketmq-dashboard/pull/4005
Fixes #TBD-ISSUE.
## Problem / Evidence
The message page's results table rebuilds the query from the *live* form
inputs on every pagination click (`message.tsx`: `onChange: (page, pageSize) =>
void executeQuery(queryMode, currentQueryParams, page, pageSize)`, where
`currentQueryParams` is recomputed from
`selectedTopic`/`dateRange`/`keyInput`/`msgIdInput` on each render, and no
input handler snapshots or clears the running query). So:
1. Run a multi-page query (e.g. topic `order-create` over a date range).
2. Change the topic select, date range, or key/msgId input **without**
clicking 查询.
3. Click page 2.
The table then silently executes the *new, uncommitted* query for page 2
while page 1 still shows the committed query's rows — the user sees one
continuous result list that is actually stitched together from two different
queries (different topic, time window, or key), with totals jumping. The same
divergence exists after replaying a stored history record.
Regression test output before the fix: after committing topic
`order-create`, selecting topic `payment-callback` in the form and clicking
page 2 fetched `payment-callback` for page 2.
## Root cause / Fix
Pagination re-queried live form state instead of the query that produced the
displayed results. Fix: keep a `committedQueryRef` that snapshots `{ mode,
params: normalizedParams }` whenever a query actually executes (in
`executeQuery` after validation, and in `replayHistoryRecord` with the record's
own parameters). Pagination calls `executeQuery(committed.mode,
committed.params, page, pageSize)`; when no query has run yet there is nothing
to paginate and the handler is a no-op.
## Priority & scoring
PRIORITY 71 = impact 27 (a core page presents results of two different
queries as one list — wrong data for operational decisions) + blast radius 12
(every multi-page message query followed by any form edit; message query is one
of the most-used flows) + reproducibility 19 (fully deterministic UI
interaction, no timing) + maintenance value 13 (aligns pagination with the
file's own generation-guard pattern for invalidating superseded queries).
FIX_CONFIDENCE 88.
## Tests
`npx vitest run src/pages/instance/__tests__/MessagePage.test.tsx
src/pages/instance/__tests__/MessagePageAsyncState.test.tsx`:
- Before the fix the new regression `paginates against the committed query
instead of live form inputs` failed: page 2 was fetched with the edited topic
(`AssertionError: expected last "vi.fn()" call to have been called with
[ObjectContaining{topic: 'order-create'}]`).
- After the fix: **28 passed (28)** (27 pre-existing + 1 new).
- Full web suite (`npx vitest run`): **Tests run: 923 passed (115 files)**,
zero failures.
- `npx tsc --noEmit` clean; `npx eslint` on touched files: no problems; `npm
run build` succeeds.
## Risk
Low. The only behavior change is which parameters a pagination click uses:
the committed snapshot instead of live inputs. Submitting 查询, mode switches and
resets already clear/replace results and now also refresh the snapshot; a
history replay updates the snapshot to the record's own parameters, so paging
after a replay re-runs the replayed query rather than a stale one.
--
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]
