unbridled-41 opened a new pull request, #5898:
URL: https://github.com/apache/rocketmq-dashboard/pull/5898
### Which Issue(s) This PR Fixes
Fixes #5897
### Problem / Evidence
The Broker tab is fed by `GET /clusters/registry`, which reports topology
only: `RocketMQClusterProvider.buildClusterVO` (`:202-216`) never sets
`config`, and `ClusterVO.config` has no builder default, so every row of that
tab carries `config: null`. `handleConfigOpen` turned that into concrete values
through its `??` fallbacks:
```ts
// web/src/pages/cluster/index.tsx (before)
const cfg: ClusterConfig = cluster.config ?? ({} as ClusterConfig);
configForm.setFieldsValue({
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,
...
});
```
and `buildConfigUpdateRequest` spreads the form into the request, which
`ClusterService.applyConfig` (`:362-390`) applies to **every broker of the
cluster** and persists. Opening the dialog and pressing 确定 without touching a
field therefore rewrote eight live broker settings - flushDiskType SYNC_FLUSH
-> ASYNC_FLUSH, fileReservedTime 168 h -> 72 h (segments deleted earlier),
maxMessageSize -> 4 MB, defaultTopicQueueNums -> 8, brokerPermission -> 6, both
auto-create switches -> false - none of which the operator chose.
The data is available: `GET /clusters/{id}` runs the same
`enrichWithLiveConfig` the instance-scoped list uses, which is why the sibling
配置差异 dialog on the same row can show the real `flushDiskType`. The suite could
not see it because the fixture supplies a full config (`ClusterPage.test.tsx`
`buildCluster()`), which is not what the registry endpoint returns.
### Root cause / Fix
The dialog treated "no config on the row" as "defaults", and its source
endpoint by design never carries one. Load the cluster detail when the dialog
opens (the row's config stays the immediate fill when present, so the
instance-scoped behaviour is unchanged), fill the form from the live config,
and when no config can be read at all show the reason and disable 确定 instead of
offering a form that would invent one.
### Priority and scoring
**PRIORITY 88** — impact 36/40 (a silent destructive write to a production
cluster: durability, retention, message size, default queue count, permission),
blast radius 18/20 (any cluster opened through the Broker tab that way),
reproducibility 18/20 (deterministic client-side payload, pinned by the new
test), maintenance value 16/20 (removes a "guess and write" path).
**FIX_CONFIDENCE 85** — the missing data source and the available one are
both verified in code; the only judgement is the unreadable-config UX, which
fails safe (no submit).
### Tests
`cd web && npx vitest run src/pages/cluster/__tests__/ClusterPage.test.tsx`
-> `Tests 32 passed`.
| Test | Before | After |
|---|---|---|
| `fills the broker config dialog from the live cluster detail, not from
fabricated defaults` | FAIL (detail never requested; form showed the 72 h
fallback instead of the live 168 h) | PASS |
| `refuses to edit a broker config it could not read instead of submitting
defaults` | FAIL (no reason shown, 确定 enabled) | PASS |
`npx eslint` reports no errors; `npx tsc -b` passes. The pre-existing
config-preview cases still pass (the row-config path is unchanged).
### Risk
One extra `GET /clusters/{id}` per dialog open (the same call the
instance-scoped list already makes), and a new read-only state when the broker
config cannot be read. Nothing else changes: the request shape, the preview,
the submit path and the instance-scoped rows are untouched.
--
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]
