apache / apache/rocketmq-dashboard

[Studio][Bug] Broker config-diff modal applies stale responses: closed dialog reopens and a slower response overwrites a newer request

Open
#3,292 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1.4k
Forks
683
Avg merge
2d 14h
Merged PRs (30d)
58

Description

## Problem

`openBrokerConfigDiff` in `web/src/pages/cluster/index.tsx` applies the `getBrokerConfigDiff` response to `brokerConfigDiffState` unconditionally, with no request generation guard. Two triggers:

1. **Closed dialog reopens:** clicking 配置差异 on a Broker row and then 关闭 before the response arrives lets the pending response re-open the dialog on its own and render the diff.
2. **Wrong cluster's data:** while cluster A's diff request is in flight, clicking 配置差异 on a cluster B row is not blocked; when A's slower response lands it overwrites the modal with A's title and A's differences, presented as if they were B's. A stale failure also clears the loading state of a newer in-flight request.

## Evidence / source

- Code inspection of the current `rocketmq-studio` branch (base commit 36126024): the sibling NameServer diff flow is guarded by `nsConfigDiffRequestRef` and has the regression test `does not reopen a closed NameServer config diff when its request finishes`; the Broker diff flow has neither a generation ref nor invalidation in either close handler.
- Deterministic Vitest reproduction with deferred promises in `ClusterPage.test.tsx` (both tests red on the unfixed source): `does not reopen a closed Broker config diff when its request finishes` and `keeps the requested broker config diff when a slower response finishes last`.

## Impact

Read-only correctness of the Broker 管理 drift view: an operator can read one cluster's config differences while believing they belong to the requested cluster, and a closed dialog can reappear. No configuration write requests are involved.

## Expected behavior / acceptance criteria

- Only the current Broker-diff request generation may publish open/loading/result state or error handling.
- Both close paths and unmount invalidate older requests.
- Regression coverage for close-before-response and slower-response-overwrites-newer-request; both must fail on the unfixed code.

## Related work

- Closed #2729 added request generations for the **NameServer** config-diff and connection-test modals; the Broker diff modal was outside that scope and remains unguarded — this issue tracks that remaining instance.
- Wrong-instance targeting of registry config actions is a separate defect tracked in #3103 (draft PR #3151).

## PR

Draft PR #3154 (includes the fix and the two regression tests).

Contributor guide

No contributing guide indexed for this repository

Research direction

Start in web/src/pages/cluster/index.tsx and compare the Broker diff flow with the guarded NameServer flow. Run the deferred-promise regressions in ClusterPage.test.tsx for closing before a response and for a slower response overwriting a newer request. Done means only the current request can affect the modal, loading state, result, or error handling, with close and unmount covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend, testing-qa
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Clearly specified
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.