swuferhong opened a new issue, #3625: URL: https://github.com/apache/fluss/issues/3625
### Search before asking - [x] I searched in the [issues](https://github.com/apache/fluss/issues) and found nothing similar. ### Fluss version 0.9.0 (latest release) ### Please describe the bug 🐞 ## Description Coordinator-side dynamic configs may become stale on an already-running standby `CoordinatorServer`. The coordinator `DynamicConfigManager` currently fetches dynamic configs from ZooKeeper during startup, but coordinator instances ignore later config change notifications. As a result, a standby coordinator does not continuously track the latest dynamic configs while it remains standby. When that standby later becomes the active coordinator, leader-only components are initialized and registered against the local `DynamicConfigManager`. If the local `DynamicServerConfig.currentConfig` is stale, those components may be configured with old values even though ZooKeeper already contains newer dynamic configs. This is not specific to one config option. It can affect coordinator-side dynamic configs in general. The issue is easier to observe with `coordinator.rebalance.max-inflight-tasks`: if users dynamically set it to `0` to pause rebalance scheduling, a coordinator failover may cause the new active coordinator to initialize `RebalanceManager` with the old value, such as the default `1`, and resume scheduling rebalance tasks unexpectedly. ## Impact After coordinator failover, the new active coordinator may not respect the latest dynamic configs stored in ZooKeeper. ## Root Cause Coordinator `DynamicConfigManager` uses `isCoordinator = true`, and the config change notification handler returns early for coordinator instances. Therefore, standby coordinators do not apply dynamic config changes after their initial startup fetch. Leader-only components, such as `RebalanceManager`, are registered when the coordinator becomes leader. Their initial configuration comes from the local `DynamicServerConfig.currentConfig`, which may be stale on a long-running standby. ## Proposed Solution Refresh dynamic configs from ZooKeeper when a standby CoordinatorServer becomes leader, before registering leader-only components. Specifically: 1. Add a method to `DynamicConfigManager`, for example: ```java public void refreshFromZooKeeper() throws Exception { Map<String, String> entityConfigs = zooKeeperClient.fetchEntityConfig(); dynamicServerConfig.updateDynamicConfig(entityConfigs, true); } ### Solution _No response_ ### Are you willing to submit a PR? - [ ] I'm willing to submit a PR! -- 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]
