Affected version: 26.4.2 (confirmed still present in 26.5.1)
Component: com.arcadedb.remote.RemoteHttpComponent (arcadedb-network)

Summary

httpCommand reads leaderServer twice (line 217 and line 330). Between the
two reads, requestClusterConfiguration / reloadClusterConfiguration can
null it (line 522). The second read at line 330 then writes null into
connectToServer; the loop guard at line 221 exits early. The request is
abandoned without a retry.

Code

network/com/arcadedb/remote/RemoteHttpComponent.java:217, 329–330, 431, 438, 449, 483, 522

// line 217:
connectToServer = leaderIsPreferable && leaderServer != null ? leaderServer : new Pair<>(currentServer, currentPort);
// line 329-330:
if (leaderIsPreferable && !currentConnectToServer.equals(leaderServer)) {
  connectToServer = leaderServer;                                          // may now be null
}
…
// line 522 (reloadClusterConfiguration):
leaderServer = null;

Impact

Under HA topology change, requests can spuriously fail with "no server
available" instead of retrying.

Suggested fix

Declare leaderServer, currentServer, currentPort as volatile (or
guard under the inherited RWLockContext); httpCommand should snapshot
the leader to a local once per iteration.