unbridled-41 opened a new issue, #5897:
URL: https://github.com/apache/rocketmq-dashboard/issues/5897
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is
based on it)
deployed as: not required to reproduce
### Runtime Environment
Reproduced with the frontend tests (`cd web && npx vitest run
src/pages/cluster/__tests__/ClusterPage.test.tsx`); no cluster needed. The live
effect needs a reachable cluster, but the request payload is decided entirely
on the client.
### Connected RocketMQ Cluster
Any cluster reachable through a NameServer registry entry; the values are
written to every broker of the cluster.
### Describe the Bug
The Broker tab is fed by `GET /clusters/registry`, which reports topology
only: `RocketMQClusterProvider.buildClusterVO` builds
name/type/status/brokers/proxies/nameServers/tpsHistory/topicCount/groupCount
and never sets `config`, and `ClusterVO.config` has no builder default. Each
row of that tab therefore carries `config: null`, and `handleConfigOpen` turns
the missing config into concrete values through its `??` fallbacks:
```ts
flushDiskType: cfg.flushDiskType ?? 'ASYNC_FLUSH',
maxMessageSizeMB: Math.round((cfg.maxMessageSize ?? 4194304) / 1048576),
fileReservedTime: cfg.fileReservedTime ?? 72,
writeQueueNums: cfg.writeQueueNums ?? 8,
readQueueNums: cfg.readQueueNums ?? 8,
brokerPermission: cfg.brokerPermission ?? 6,
```
`buildConfigUpdateRequest` spreads those form values into the request, and
`ClusterService.applyConfig` applies them to every broker of the cluster and
persists them in Studio's own record. Opening the dialog and pressing 确定
without touching a field therefore rewrites eight live broker settings with
values the operator never chose:
- durability: `flushDiskType` SYNC_FLUSH -> ASYNC_FLUSH
- retention: `fileReservedTime` (e.g. 168 h) -> 72 h, so segment files are
deleted earlier
- `maxMessageSize` -> 4 MB, `defaultTopicQueueNums` -> 8, `brokerPermission`
-> 6, both auto-create switches -> false
The sibling 配置差异 dialog on the same row proves the data is available: it
reads the live config server-side (`/clusters/{id}/broker-config-diff`), so it
can show `flushDiskType=SYNC_FLUSH` while the config dialog shows 异步刷盘.
The suite cannot see it because the test fixture and the mock both supply a
full config (`ClusterPage.test.tsx` `buildCluster()` sets `flushDiskType:
'SYNC_FLUSH'`, `fileReservedTime: 72`, ...), which is not what the registry
endpoint returns.
### Steps to Reproduce
1. Register a NameServer entry and open Cluster -> Broker.
2. Click 配置 on any broker row: the dialog shows ASYNC_FLUSH / 4 MB / 72 h /
8+8 queues / 读写.
3. Press 确定. Every broker of that cluster receives those values, whatever
the cluster ran before.
### What Did You Expect to See?
The dialog shows the cluster's actual configuration, and an unreadable
configuration is reported as such instead of being replaced by defaults.
### What Did You See Instead?
Invented values that are indistinguishable from real ones, and a submit that
writes them to the cluster.
### Evidence
- `web/src/pages/cluster/index.tsx` (`handleConfigOpen`,
`buildConfigUpdateRequest`, the Broker rows built from `registryClusters`).
- `server/.../provider/apache/RocketMQClusterProvider.java:202-216`
(`buildClusterVO` sets no config),
`server/.../cluster/broker/ClusterService.java:97-105` (`listRegistryClusters`
does not call `enrichWithLiveConfig`, unlike `listClusters`/`getCluster`),
`:362-390` (`applyConfig`), `web/src/services/clusterService.ts:20-35`
(`copyCluster` even assumes a non-null config).
- `cd web && npx vitest run
src/pages/cluster/__tests__/ClusterPage.test.tsx` - the new case reports that
the dialog never asked for the cluster detail and showed the 72 h fallback.
### Impact
A destructive, silent write to a production cluster (durability, retention,
message size, queue counts, permission) triggered by opening a dialog and
confirming it.
### Acceptance Criteria
- The dialog reads the live config before it can submit anything, shows the
real values, and refuses to edit (with a visible reason) when the config cannot
be read, with regression tests for both paths.
**Corresponding PR:** #5896
--
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]
