Repository navigation
[client] Expose all coordinator servers (leader and standbys) via the client API #4117
Description
Search before asking
- I searched in the issues and found nothing similar.
Motivation
Since coordinator HA (1.0), a cluster may run several coordinator servers, but the client API still surfaces exactly one: MetadataResponse carries a single coordinator_server (the current leader), and Admin#getServerNodes() returns that node plus the alive tablet servers. Standby coordinators are invisible to clients — they reject every request except apiVersions with NotCoordinatorLeaderException.
Operational tooling (consoles, operators, CLIs) needs to display and verify the HA topology: how many coordinators exist, which one is the leader, and whether the standbys are alive. Today the only sources are out-of-band — ZooKeeper or the deployment platform (for example, Kubernetes pods) — which not every client can or should reach.
Solution
- Expose all registered coordinator servers with a role marker (leader/standby) through the client API — either by extending
getServerNodes/MetadataResponse, or as part of the cluster-info API proposed in [rebalance] Change the implementation of Admin#getServerNodes() as introducing a new API to get cluster information #1389, or as a dedicatedAdmin#describeCoordinators(). - Include a liveness signal per coordinator (for example, presence in the election group), so a dead standby is distinguishable from a live one.
Related: #4105 needs a readiness signal that is valid for standby coordinators; a client-visible role/liveness API could serve that consumer too. The request handler's blanket rejection of all non-leader requests is already marked as provisional in a code comment (FlussRequestHandler) — serving this (read-only) call from a standby would be consistent with narrowing that check.
Anything else?
Affected areas: fluss-rpc (FlussApi.proto: metadata or a new describe message), fluss-server (CoordinatorService, election-group state), fluss-client (Admin).
Willingness to contribute
- I'm willing to submit a PR!
Activity
striver619 commentedon Aug 27, 2026
@affo
i already add this pr: #4111 about coordinator ha
affo commentedon Aug 31, 2026
@striver619 thanks for the pointer!
This issue is about adding the information of standby replicas into the Fluss RPC calls, I think your PR is about documentation.
Am I missing something?
MaheshS08 commentedon Sep 4, 2026
@affo, I would like to work on this issue. I'll implement the feature to expose all coordinator servers (leader and standbys) via the client API with the following approach:
CoordinatorRoleenum to distinguish between leader and standby coordinatorsPbCoordinatorServerInfo) to include coordinator role and liveness information inMetadataResponse/coordinators/ids) with their current role (from/coordinators/active)Admin#getServerNodes()to return all coordinators (leader + standbys) along with tablets serversClusterandMetadataUpdaterto track and expose all coordinatorsThis will enable operational tooling to:
The implementation will maintain backward compatibility while providing the new visibility into the coordinator HA setup.