ai-yang opened a new issue, #3103:
URL: https://github.com/apache/rocketmq-dashboard/issues/3103
# [Studio][Bug] Registry Broker configuration actions can target the wrong
instance
## Severity
High (P1). This is a silent control-plane write to a different RocketMQ
instance than the Broker row selected by the operator.
## Problem
The Cluster page displays Broker rows from the global NameServer registry
through `listRegistryClusters()`. Broker configuration preview/update and
config-diff actions still attach the instance selected by the page route.
After registry-based discovery was introduced, the current route instance
and the source instance of a registry row are no longer necessarily the same.
If two instances use a common cluster name such as `DefaultCluster`, selecting
a row discovered from instance B while the route points to instance A sends `{
id: "DefaultCluster", instanceId: "instance-a" }`. The backend correctly honors
that payload and can update A even though the operator clicked B.
## Reproduction
1. Configure two Apache instances:
- `instance-a` -> `ns-a:9876`
- `instance-b` -> `ns-b:9876`
2. Let both NameServers report a cluster named `DefaultCluster`, with
different Broker addresses.
3. Register `ns-b:9876` in the NameServer registry.
4. Open `/cluster?instanceId=instance-a`.
5. In the global Broker table, open configuration for a Broker discovered
from `ns-b:9876` and submit a change.
### Actual behavior
The update request contains:
```json
{
"id": "DefaultCluster",
"instanceId": "instance-a"
}
```
The backend resolves and updates instance A.
### Expected behavior
Every registry row action must be routed through the unique Apache instance
whose endpoint owns that row. If ownership cannot be established unambiguously,
configuration actions must fail closed.
## Impact
The operation can silently change the wrong production cluster's flush mode,
auto-create settings, queue counts, maximum message size, retention, or
permissions. A successful response does not reveal that the target was wrong.
## Root cause
- `web/src/pages/cluster/index.tsx` loads all registry clusters without
instance scope.
- Broker rows retain their registry cluster but no source instance identity.
- `buildConfigUpdateRequest` and Broker config diff previously read
`selectedInstanceIdRef.current`, which represents the route, not the row.
## Regression boundary / duplicate check
- #1243 / #1244 added the selected-instance API contract, but #1243
explicitly left broader cluster discovery/action routing out of scope.
- #2342 later moved the Broker table to global registry discovery without
assigning an instance identity to each row.
- #2595 concerns repeated config reads for duplicate Broker addresses, not
writes to the wrong instance.
- Searches for `listRegistryClusters updateClusterConfig` and equivalent
registry/selected-instance terms found no issue or PR covering this failure.
## Suggested acceptance criteria
- Canonicalize the full NameServer address set and map a registry endpoint
to exactly one Apache instance.
- Use the row's instance for Broker configuration preview, update, and
config diff.
- Freeze the target when a modal opens so a later route change cannot
retarget the write.
- Discard preview/diff responses from a closed, superseded, or edited modal
generation.
- Refresh the global registry snapshot after successful and partially
successful updates.
- Disable configuration actions for missing or ambiguous mappings.
- Preserve global registry visibility.
- Cover cross-instance, route-change, address-order/separator, and
ambiguous-mapping cases in tests.
--
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]
