Affected version: ArcadeDB server 26.4.2
Component: HA / cluster topology endpoint (server?mode=cluster)

Summary

In a 3-node HA cluster, repeated calls to /api/v1/server?mode=cluster (issued by RemoteHttpComponent.requestClusterConfiguration() on every new RemoteDatabase instance) return different topology views depending on which node serves the call. Two distinct response shapes are observed within seconds of each other:

Two anomalies in the inconsistent case:

1. arcadedb-2 is missing entirely from the cluster view.
2. The leader (arcadedb-0) is listed inside replicas, which contradicts the "correct" view (where replicas excludes the leader).

The cluster is healthy — all 3 pods are up — and the StatefulSet did not restart between the calls.

Reproduction

1. Run ArcadeDB 26.4.2 as a 3-node HA cluster on Kubernetes (StatefulSet + headless Service).
2. From a client (or any HTTP tool), issue many GET /api/v1/server?mode=cluster calls through the K8s Service hostname so requests round-robin across pods.
3. Compare the leader and replicas fields across responses.

Expected: identical answer regardless of which node handled the call.
Actual: at least two different shapes, including one that omits a real cluster member and one that duplicates the leader into replicas.

Impact

• The Java client (RemoteHttpComponent.requestClusterConfiguration()) caches whichever view it received at construction time. With a per-operation new RemoteDatabase(...) pattern, the client's view of the cluster flips between calls.
• Combined with the separately-reported STICKY strategy no-op, this means client load distribution and failover behave non-deterministically.
• Operationally it makes monitoring/tooling unreliable — a status panel polling this endpoint reports different cluster shapes depending on which pod answered.

Questions for the team

1. Is replicas intended to include or exclude the leader? Please document the contract; both shapes are currently observed.
2. Under what conditions can a node be missing from mode=cluster even when it is a healthy quorum member (visible to the other nodes)? Is this an eventually-consistent view that hasn't converged, a per-node caching bug, or something else?
3. Is there a way to query the topology from a single authoritative source (e.g., always from the leader)?

Environment

• ArcadeDB 26.4.2, 3-pod StatefulSet on Kubernetes
• Headless Service vcc-superx-arcadedb in namespace contact-center
• Client: arcadedb-network 26.4.2, Java 21