zmuxuny opened a new issue, #6361:
URL: https://github.com/apache/rocketmq-dashboard/issues/6361

   ### Before Creating the Bug Report
   
   - [x] I have searched the [open 
issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository 
and believe that this is not a duplicate.
   
   - [x] This is a defect in RocketMQ Studio, not a usage question and not a 
defect in another Apache RocketMQ repository.
   
   - [x] I can reproduce this on the current `master` branch, or I have stated 
the exact version I am running below.
   
   
   ### Studio Version
   
   rocketmq-studio@779b8c0e7aed2396d3cc72743dcd544ea48e9ae6. Reproduced from 
the unchanged source in frontend tests.
   
   ### Runtime Environment
   
   Linux cloud workspace, Node.js 24.19.0, Vitest 4.1.10, React 18, Ant Design 
5 and jsdom. No live deployment, broker or database was used.
   
   ### Connected RocketMQ Cluster
   
   Not required for the deterministic frontend reproduction. Only synthetic 
records and mocked service responses were used.
   
   ### Build Toolchain
   
   _No response_
   
   ### Describe the Bug
   
   On Client Connections, a failure while querying a selected physical cluster 
resets the cluster filter to ALL. This triggers an unsolicited broader query. 
If that broader read succeeds, it clears the error and displays connections 
from unrelated clusters, so the requested cluster failure is lost instead of 
being available for retry.
   
   ### Steps to Reproduce
   
   1. Open Client Connections with a registered NameServer returning 
connections for two clusters.
   2. Select one cluster in the top-level cluster filter.
   3. Fail that filtered service call once, while an unfiltered call would 
succeed.
   4. Observe the subsequent request and error/selection state.
   
   ### What Did You Expect to See?
   
   Keep the selected cluster and the failure visible, clear unusable rows, and 
let Retry request the same NameServer, cluster and type. An explicit NameServer 
switch may still reset filters as before.
   
   ### What Did You See Instead?
   
   The connection effect catch calls setClusterFilter("ALL"), causing a third 
API request without clusterId after the initial all-cluster and 
selected-cluster requests. Its success replaces the failure and shows all 
clusters. A real-component red regression expecting two calls gets three 
immediately after rejecting the deferred selected-cluster request.
   
   ### Additional Context
   
   Source: 
https://github.com/apache/rocketmq-dashboard/blob/779b8c0e7aed2396d3cc72743dcd544ea48e9ae6/web/src/pages/cluster/clients.tsx#L252-L268
   
   Searched clients/filter/failure, client/retry/cluster and client/ALL issues 
and PRs. #1709 added current-endpoint Retry, #4240 and #4595 reset filters on 
an explicit NameServer switch; none intends to silently broaden a failed 
request.
   
   Red reproduction: npm test -- --maxWorkers=1 
src/pages/cluster/__tests__/ClientsPage.test.tsx -t "preserves the selected 
cluster after". One expected assertion failure, 24 skipped, unchanged 
production. The actual page and cluster selector are rendered; coherent 
query-dependent mock responses model the failed cluster and successful 
unfiltered read. Planned controls include retained type/search, successful 
retry and superseded failures. No real broker or full-suite result is claimed. 
AI assistance was used for investigation and tests.
   
   ### Are You Willing to Submit a Pull Request?
   
   - [x] Yes, I am willing to submit a pull request.


-- 
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]

Reply via email to