[Bug] Broker cluster live refresh toasts and blanks the topology on every failing 2s tick

Open Beginner friendly
#5,644 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
react, typescript
Domain
frontend

Research direction

Read loadData and the live-refresh poller in web/src/pages/studio/BrokerCluster.tsx, then inspect web/src/pages/studio/__tests__/BrokerCluster.test.tsx for the existing component-test setup. Add a test for a successful load followed by a rejected automatic poll. Done means the last good topology remains visible and the automatic failure shows no toast, while an explicit refresh still reports failure.

Written by the indexing model from the issue text.

Description

Before Creating the Bug Report
  • I have searched the open issues of this repository and believe that this is not a duplicate.
  • This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository.
  • I can reproduce this on the current master branch, or I have stated the exact version I am running below.
Studio Version

branch: rocketmq-studio
git commit id: 6a68042f
deployed as: built from source

Runtime Environment

OS: Ubuntu 22.04 (WSL2)
MySQL: not applicable — the defect is in the page's polling/error path, covered by the component test
browser: not needed; reproduced with the page's own component test (web/src/pages/studio/__tests__/BrokerCluster.test.tsx)

Connected RocketMQ Cluster

RocketMQ version: not applicable — mock mode serves the fixture cluster
access mode: not applicable
deployment: not applicable

Describe the Bug

On the cluster topology page (web/src/pages/studio/BrokerCluster.tsx), with live refresh switched on, the page polls listClusters every 2 s. Every failing tick runs the same error path as a manual refresh: it calls clearData() and shows an error toast. A transient outage of the instance/server therefore turns into an endless loop of "refresh failed" toasts every 2 seconds, and the topology the operator is looking at is blanked between ticks even though the last successful data was already fetched.

loadData() has no silent mode: the poller, the initial load and the manual refresh all share one loud failure path.

Steps to Reproduce
  1. Open the cluster topology page for an instance and switch live refresh on.
  2. Make the next listClusters call fail (stop the instance, or point the page at an unreachable server).
  3. Watch two or three refresh intervals: an error toast appears on every tick and the topology table empties, although data had already been loaded successfully.
What Did You Expect to See?

A failing automatic tick should stay quiet — no toast, keep the last good topology — and only an explicit refresh should report the failure. That is already the behaviour of the consumer page's auto-refresh (the silent-refresh pattern introduced for #4968).

What Did You See Instead?

common.refreshFailed toast on every 2 s tick plus clearData() blanking the table, for as long as the outage lasts.

Additional Context
  • affected code: loadData in web/src/pages/studio/BrokerCluster.tsx, shared by the initial load, the refresh button and the live-refresh poller.
  • the failing-tick behaviour can be pinned with a component test: with a resolved fixture followed by a rejected poll, the unpatched page clears the table and toasts on the silent tick.
Are You Willing to Submit a Pull Request?
  • Yes, I am willing to submit a pull request.

Re-submission: the original report (#5074) was closed by the stale bot after 7 days without triage activity, and GitHub now rejects reopening items in this repository. Refiled unchanged; the fix PR is linked below.

Dominant language
Java
Stars
1.4k
Forks
718
Avg merge
3d 16h
Merged PRs (30d)
215

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq-dashboard

All issues in apache/rocketmq-dashboard

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.