[Bug] Broker cluster live refresh toasts and blanks the topology on every failing 2s tick
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
masterbranch, 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
- Open the cluster topology page for an instance and switch live refresh on.
- Make the next
listClusterscall fail (stop the instance, or point the page at an unreachable server). - 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:
loadDatainweb/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
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from apache/rocketmq-dashboard
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
apache/rocketmq-dashboard#5672 · 1 comment ·
Maintainers usually reply within 3 days
-
[Bug] DLQ timestamps shift with the JVM zone while every other zoneless datetime is UTCPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
apache/rocketmq-dashboard#5587 · 1 comment ·
Maintainers usually reply within 3 days
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 47/100
apache/rocketmq-dashboard#7398 ·
Maintainers usually reply within 3 days
-
[Feature]Openenhancement
Difficulty 5/5 Over a week Newbie friendliness 8/100
apache/rocketmq-dashboard#7376 ·
Maintainers usually reply within 3 days
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 12/100
apache/rocketmq-dashboard#6027 · 1 comment ·
Maintainers usually reply within 3 days
All issues in apache/rocketmq-dashboard
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
WalletConnect/walletconnect-monorepo#7389 · 1 comment ·
-
help wanted testing
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
elhajahmadj/offline-emergency-library#108 ·
Maintainers usually reply within 1 day
-
Add documentation for Transaction-bound OTP generationPossibly taken @radimtrojek-rgb claimed this today. Opendocumentation
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
wultra/powerauth-nextstep#86 ·
-
API `/api/dataverses/{identifier}/dataset/linkingDataverses?alreadyLinking=true` returns at most 1 collectionPossibly taken A pull request linked to this issue is open or already merged. OpenType: Bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
OpenLineage/OpenLineage#5138 ·
Maintainers usually reply within 2 days