yyqdbngt opened a new pull request, #2865:
URL: https://github.com/apache/rocketmq-dashboard/pull/2865
## Summary
- `ClusterService.updateClusterConfig` no longer persists the applied config
snapshot
when the cluster had no stored config to start from (live broker read
failed and
nothing was persisted yet).
- Persistence now happens before the in-memory cluster is mutated, so a
persistence
failure leaves the previous snapshot untouched (previously pinned
behaviour, kept).
- Updated the null-config regression test to the new semantics and added
`updateConfigShouldSkipSnapshotPersistenceWhenNoStoredConfigExists` /
`updateConfigShouldPersistSnapshotWhenStoredConfigExists`.
## Why
`copyConfig(null)` yields a VO padded with zero defaults. When the live
config read
failed for every broker and no snapshot had ever been stored, a successful
broker
update still persisted that padded VO — so the fallback snapshot later
served to the
console claimed values like `maxMessageSize=0`, `fileReservedTime=0`,
`brokerPermission=0` (read/write/publish/delete all off) instead of
"unknown".
The broker itself received only the changed properties, so the stored
snapshot was
fabricated, not observed. Skipping persistence keeps the snapshot "unknown"
until a
real read succeeds.
## Testing
- `cd server && mvn -Dtest=ClusterServiceTest test` — Tests run: 41,
Failures: 0, Errors: 0
- `cd server && mvn -Dtest=ClusterControllerTest test` — Tests run: 34,
Failures: 0, Errors: 0
--
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]
