iloveeyjafjalla opened a new issue, #6294: URL: https://github.com/apache/rocketmq-dashboard/issues/6294
### Before Creating the Bug Report - [x] Searched all-state Issues/PRs and inspected relevant current head differences and all public comments. - [x] This is a RocketMQ Studio frontend defect in this repository. - [x] Reproduced on the exact revision below. ### Studio Version `rocketmq-studio@5e4c39b053c35a5598cc79ff331b8a54e649d7b1`. ### Runtime Environment / Build Toolchain Windows 11, Node 24.15.0, npm 11.12.1. Automated reproduction uses real TopicPage rendering and pagination with controlled service responses. No deployment or network-outage experiment was performed. ### Connected RocketMQ Cluster No broker or database was contacted. The affected frontend path calls the ordinary Topic consumer pagination service for the selected instance. ### Describe the Bug `openDetail` catches a failed initial consumer request, but the consumer table's later `onChange` directly calls the same async loader with `void` and no rejection handler. A timeout after a successful initial load therefore produces an unhandled rejection and no Topic detail error message. The previous successful rows and controlled page remain visible. ### Steps to Reproduce 1. Open a Topic's detail with at least two consumer pages. Let page 1 load successfully. 2. Click consumer page 2. 3. Let that consumer-page request reject with a network/timeout error without a business-response envelope. 4. Observe the old page remains visible without the existing Topic detail failure feedback. The pagination promise rejects without being handled. The deterministic regression supplies twenty ordinary page-1 rows with total 40, clicks the actual page-2 control, and rejects only that page request. The old-code assertion cannot find `Topic 详情加载失败，请稍后重试`; Vitest also identifies the unhandled rejection from the real pagination callback. ### What Did You Expect to See? A failed page request is handled and reported. The last successfully loaded page can remain visible, and the user can retry the requested page. A late failure from a superseded request or a closed/departed detail must not report against the current view. ### What Did You See Instead? The later pagination callback has no catch. Initial-open handling is bypassed, and the failed request does not update or notify the Topic page. For business-envelope failures the shared client may already show a global message; that does not handle the returned pagination promise, and the timeout path above has no such envelope. ### Additional Context Related #5472 / merged #5442 handles initial detail loading and independent route lookup. This report concerns the subsequent consumer pagination callback after both initial requests succeed. Current #6093 changes route verdicts, and #5495 clears failed Topic inventory loads; their actual diffs do not catch this callback. The proposed fix reuses the existing error message and guards its publication with consumer/detail request generations. The PR records actual red/green tests, static checks and build results. No API schema, consumer record semantics or broker operation changes. AI assistance: OpenAI Codex investigated, implemented and verified the change, with separate automated review. No live incident, external human review or maintainer approval is claimed. ### Are You Willing to Submit a Pull Request? - [x] Yes. ### Implementation PR https://github.com/apache/rocketmq-dashboard/pull/6293 -- 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]
