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

   ## Before Creating the Bug Report
   
   - [x] I searched open and closed Issues/PRs for Proxy topology, stale lists, 
and out-of-order loads. The earlier #1336 addressed late *home-page* responses; 
this is the later health-probe failure path.
   - [x] This is a RocketMQ Studio frontend defect.
   - [x] The affected code is on the current `rocketmq-studio` branch at 
`0228dad5`.
   
   ## Studio Version
   
   `apache/rocketmq-dashboard` branch `rocketmq-studio`, commit `0228dad5`, 
built from source.
   
   ## Runtime Environment
   
   Frontend: React/Vite in the repository. The failure sequence can be 
reproduced with controlled Proxy API responses; no browser-specific or 
backend-specific behavior is required.
   
   ## Connected RocketMQ Cluster
   
   Any configured Proxy address list. A live cluster is not needed to reproduce 
this frontend request-order race.
   
   ## Describe the Bug
   
   The Proxy page already tracks a request ID so an older list load cannot 
overwrite a newer one. However, `applyProxyHome` checks that ID only when 
`getProxyTopology()` *succeeds*. If an older health probe rejects, the `catch` 
falls through to `setProxyNodes(nodes)` without checking whether a newer list 
has already been applied. A failed optional health probe can therefore restore 
removed/outdated Proxy addresses and selection in the UI.
   
   ## Steps to Reproduce
   
   1. Let an earlier list request return address A, but keep its 
`getProxyTopology()` call pending.
   2. Start a newer load (for example, after removing A) and let it apply an 
address list without A.
   3. Reject the earlier `getProxyTopology()` call.
   4. Observe that the earlier address list is applied again.
   
   ## What Did You Expect to See?
   
   Only the latest active list request should update nodes, statistics, local 
storage, or the selected address, regardless of whether its optional health 
probe succeeds or fails.
   
   ## What Did You See Instead?
   
   The old address reappears after the older health probe fails, even though 
the newer list has already been rendered.
   
   ## Additional Context
   
   The current out-of-order test covers an older `queryProxyHomePage()` 
response arriving late. This is a different ordering: the older home response 
arrives first, then its health probe fails after the newer list has committed. 
I plan to add a deterministic deferred-promise regression for this path.
   
   - [x] 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