unbridled-41 opened a new issue, #4165:
URL: https://github.com/apache/rocketmq-dashboard/issues/4165
## Problem
On the Cluster page (Broker 管理 tab), the broker config preview dialog
renders whichever `previewClusterConfig` response arrives last, without any
request-generation guard. Every comparable request on the same page already
guards against stale responses: `nsConfigDiffRequestRef`,
`brokerConfigDiffRequestRef`, `connectionTestRequestRef`, plus the registry
lists (`web/src/pages/cluster/index.tsx`). `handleConfigPreview` alone does not.
## Evidence
- `handleConfigPreview` awaits `previewClusterConfig(request)` and then
unconditionally calls `setConfigPreview(preview)`, `message.success(...)`, and
`setConfigPreviewLoading(false)`.
- Reproduction path: open 配置 for a broker, change a value, click 预览
(response A is slow) → close the dialog (Cancel) → reopen 配置 for the same
broker, change values again, click 预览 (response B arrives) → slow response A
finally resolves → the panel now shows A's diff although the form holds
different values.
- A new regression test (`discards a superseded broker config preview
response`) fails on the unmodified base: the final assertion
`getByText('defaultTopicQueueNums=24')` finds only `defaultTopicQueueNums=16` —
the stale first preview overwrote the latest one. The dialog was also
re-rendered with `configPreviewLoading` still stuck from the superseded
request's `finally` being bypassed by the newer one, and the success toast
fires for the stale response.
- Same-file precedent: `keeps the requested broker config diff when a slower
response finishes last` (added by the fix for the broker config diff race)
exercises the identical pattern with a request ref guard.
## Impact
The preview panel is the safety check users rely on before applying a broker
config update across a cluster. Showing a diff computed from values that are no
longer in the form (or a stale success toast while the panel is still loading)
invites confirming an update whose preview does not match what will be applied.
## Expected behavior
Each preview request carries a generation; only the newest one may write
`configPreview`/`configPreviewLoading` or toast. The generation must be
invalidated when the dialog opens, when it is closed, and when any form value
changes (the existing `onValuesChange` already clears the stale preview panel).
## Related work
- #3292 / its fix PR addressed the same class of race for the broker config
diff dialog.
- The connection-test guard and NameServer diff guard already exist in the
same file; this gap is only the config preview/submit path.
- No open or closed issue covers the preview request ordering.
## PR
Fix incoming.
--
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]
