You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "X-LightYear (via GitHub)" <gi...@apache.org> on 2026/09/18 06:05:33 UTC
[I] [Studio][Bug] Topic sync modal can display stale route-check results [rocketmq-dashboard]
X-LightYear opened a new issue, #4547:
URL: https://github.com/apache/rocketmq-dashboard/issues/4547
### 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
branch: master
git commit id: d50ffecc9d7e8f8f46da64198831bd7952e6974e
deployed as: docker compose
### Runtime Environment
OS: Windows 11
MySQL: not required for this reproduction
browser: Google Chrome 127.0.6533.120 (64-bit) on Windows 11
### Connected RocketMQ Cluster
RocketMQ version: 5.5.0
access mode: not relevant to this frontend race reproduction
deployment: docker compose from deploy/rocketmq
### Build Toolchain
_No response_
### Describe the Bug
The Topic sync modal can apply a stale asynchronous route-check result after a newer sync check has already completed.
If the modal is closed and reopened while the previous route-check request is still pending, the older request can later overwrite the result of the new modal session.
This can cause the UI to report missing Broker routes even after the latest sync check has already confirmed that all Topics have valid routes.
### Steps to Reproduce
1. Open the Topic page.
2. Click "Sync Data" and keep the first route-check request pending.
3. Close the sync modal.
4. Open "Sync Data" again, starting a second route-check request.
5. Resolve the second request with a valid Broker route.
6. Confirm that the UI reports that all Topics have routes.
7. Resolve the first request afterward with an empty route list.
8. Observe that the stale first request changes the current modal result to report missing routes.
This sequence is reproducible deterministically with deferred Promises in a frontend regression test.
### What Did You Expect to See?
Only the latest route-check request for the current sync-modal session should be allowed to update the UI.
After the second request confirms that all Topics have valid routes, completion of the older request should be ignored and the healthy result should remain visible.
### What Did You See Instead?
The newer request completes successfully and the UI reports that all Topics have valid routes.
When the older request completes afterward, it updates the current sync state and the UI incorrectly changes to report missing routes.
### Additional Context
The issue is in:
`web/src/pages/instance/topic.tsx`
Function:
`openSyncModal`
The asynchronous route-check flow updates shared state such as:
- `routesByTopic`
- `syncMissing`
- `syncChecking`
without tracking which modal session or request generation owns the result.
As a result, overlapping route-check requests update the same state in completion order rather than request ownership order.
A deterministic Vitest regression test was added locally:
`web/src/pages/instance/__tests__/TopicPage.test.tsx`
Test:
`keeps a reopened sync modal owned by its newest route check`
The test uses deferred Promises to:
1. keep the first route check pending;
2. close and reopen the sync modal;
3. resolve the newer check with a valid route;
4. confirm that the healthy result is rendered;
5. resolve the stale request with no route;
6. verify that the stale result must not replace the current result.
The current production implementation fails the final assertion.
Existing TopicPage tests still pass:
- 26 existing tests passed
- only the new regression test failed
Frontend lint for the modified test file passes, and `npm run build` also passes.
The expected fix scope is frontend-only Topic synchronization modal state management.
No backend API or RocketMQ protocol change is required.
### 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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] Topic sync modal can display stale route-check results [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins commented on issue #4547:
URL: https://github.com/apache/rocketmq-dashboard/issues/4547#issuecomment-5758382217
Resolved by #4548 (merged into rocketmq-studio as c9795c1b7).
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] Topic sync modal can display stale route-check results [rocketmq-dashboard]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #4547:
URL: https://github.com/apache/rocketmq-dashboard/issues/4547#issuecomment-5726454604
**Issue Evaluation**
Category: `bug` | Status: **Confirmed**
The reported race condition in the Topic sync modal has been verified against the current codebase (`master` at `d50ffecc`).
**Root Cause:** `openSyncModal` in `web/src/pages/instance/topic.tsx` (line 566) fires async route-check requests without a request-ID guard. Other async flows in the same file (`loadTopicData`, `loadConsumers`, `openDetail`) already use the `requestIdRef` pattern to discard stale responses, but `openSyncModal` does not. When the modal is closed and reopened while a previous check is still pending, the older response overwrites the newer state.
**Impact:** The sync modal can display stale "missing routes" results after a newer check has already confirmed all routes are valid. This is a UI-only issue — no backend or data corruption risk.
**Severity:** Low–Medium. The bug is deterministic under the described reproduction steps but only affects the diagnostic display, not actual topic synchronization.
**Fix scope:** Frontend-only. Add a `syncRequestIdRef` (or reuse the existing modal session lifecycle) to discard route-check results from superseded modal sessions. The same pattern already exists in the file and can be applied consistently.
An automated fix proposal may be generated. Reply `/approve` to proceed with PR generation.
---
*Automated evaluation by RockteMQ-AI*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] Topic sync modal can display stale route-check results [rocketmq-dashboard]
Posted by "lizhimins (via GitHub)" <gi...@apache.org>.
lizhimins closed issue #4547: [Studio][Bug] Topic sync modal can display stale route-check results
URL: https://github.com/apache/rocketmq-dashboard/issues/4547
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Bug] Topic sync modal can display stale route-check results [rocketmq-dashboard]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #4547:
URL: https://github.com/apache/rocketmq-dashboard/issues/4547#issuecomment-5726442104
**Issue Evaluation**
Category: | Status: **Confirmed**
The reported race condition in the Topic sync modal has been verified against the current codebase ( at ).
**Root Cause:** in (line 566) fires async route-check requests without a request-ID guard. Other async flows in the same file (, , ) already use the pattern to discard stale responses, but does not. When the modal is closed and reopened while a previous check is still pending, the older response overwrites the newer state.
**Impact:** The sync modal can display stale "missing routes" results after a newer check has already confirmed all routes are valid. This is a UI-only issue — no backend or data corruption risk.
**Severity:** Low–Medium. The bug is deterministic under the described reproduction steps but only affects the diagnostic display, not actual topic synchronization.
**Fix scope:** Frontend-only. Add a (or reuse the existing modal session lifecycle) to discard route-check results from superseded modal sessions. The same pattern already exists in the file and can be applied consistently.
An automated fix proposal may be generated. Reply to proceed with PR generation.
---
*Automated evaluation by RockteMQ-AI*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org