apache / apache/rocketmq-dashboard

[Studio][Bug] Message list pagination re-queries with uncommitted form inputs, mixing two queries into one list

Open
#4,009 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1.4k
Forks
683
Avg merge
2d 14h
Merged PRs (30d)
58

Description

## Problem

On the message page, clicking a pagination link re-queries the server with whatever the form inputs currently hold — not with the query that produced the displayed results. Editing the topic, date range or key/msgId after running a query and then paging silently executes a different query, so the table shows rows stitched together from two different queries.

## Evidence

`web/src/pages/instance/message.tsx` recomputes `currentQueryParams` from the live inputs on every render (`:429-434`) and the table's pagination handler passes it straight to `executeQuery` (`:1206-1214`); no input handler snapshots the committed query or clears results (only mode change and reset do).

Reproduction (deterministic): run a multi-page topic query for `order-create`, change the topic select to `payment-callback` without clicking 查询, then click page 2 — the page-2 fetch runs with `payment-callback` while page 1 still shows `order-create` rows. The regression test added with the fix fails before the patch with exactly this divergence.

## Impact

One of the most-used flows presents a mixed result list with a jumping total; an operator scrolling pages believes they are reading one continuous query result.

## Expected behavior

Pagination re-runs the committed query (the mode and normalized parameters that produced the currently displayed results). Editing form inputs alone must not change what a pagination click fetches until 查询 is submitted again. Replaying a stored history record updates the committed query to the record's own parameters.

## Related work

#2529/#2531 introduced server-side paging for this page; #2601 (closed) fixed duplicate history rows written by pagination; #1805/#1810 covered out-of-range task pages. None cover the live-input re-query on pagination.

## PR

#4005

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in web/src/pages/instance/message.tsx, especially currentQueryParams at lines 429-434 and the pagination handler at lines 1206-1214. Reproduce the divergence by changing the topic after submitting a multi-page query, then review PR #4005 and its regression test. Done means pagination continues using the committed query until a new query is submitted, while replayed history uses its own parameters.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.