[release] fix(lib-jedis-pool): find the cluster primary by probing, not from CLUSTER SHARDS (1.3.1)

[pditommaso]

Summary

An alternative to #149 for #148. Like #149, it keeps redis.mode=cluster-primary connected through a MemoryDB failover. Instead of teaching discovery to read MemoryDB's CLUSTER SHARDS reply, it stops reading the topology altogether.

How discovery works now: each address of the discovery endpoint (clustercfg.…) is probed with the key already used to validate pooled connections (jedis-pool:primary-probe):

• the primary answers, and is the one used;
• a replica answers MOVED to its primary, which is confirmed with the same probe;
• a node that is unreachable or answers CLUSTERDOWN is skipped, and the next address is tried.

Why this instead of #149

• It doesn't depend on what MemoryDB reports. The second entry in stage's reply was never captured. [release] fix(lib-jedis-pool): stay connected through a MemoryDB failover that lists the failed primary as an extra shard (1.3.1) #149 handles it only if the failed primary is listed without slots. Probing works whatever the entry holds, because each node answers from its current role.
• It removes a class of bugs instead of patching one more case. The topology is unreliable during a failover: 1.3.0 already special-cased two master nodes in one shard, and [release] fix(lib-jedis-pool): stay connected through a MemoryDB failover that lists the failed primary as an extra shard (1.3.1) #149 adds slotless entries. Here there's nothing to special-case.
• CLUSTERDOWN no longer ends discovery for an address. On stage the returning old primary answered CLUSTERDOWN (12:51:30). In 1.3.0 and [release] fix(lib-jedis-pool): stay connected through a MemoryDB failover that lists the failed primary as an extra shard (1.3.1) #149 that error stops probing the remaining candidates from that address.
• Fewer permissions: the Redis user no longer needs @slow, only read access to the probe key.
• Less code: primariesOf and the TLS-port and endpoint parsing are gone (−66/+40 in JedisConnector).

Replaying the stage failover

JedisConnectorMemoryDbFailoverTest replays the stage timeline against two fake nodes (a minimal RESP server, no Docker): the old primary goes down and the promoted node's CLUSTER SHARDS lists it as an extra shard. Since the real entry is unknown, each plausible shape is a variant. The table is the result of running the same scenario against each version; "stuck" means no successful write until the reply is single-shard again.

Second entry in the promoted node's reply	1.3.0	#149	this PR
failed primary, no slots, fail	stuck (found 2 shards)	recovers	recovers
failed primary, no slots, still online	stuck	recovers	recovers
failed primary, still owning the slots	stuck	stuck	recovers
promoted node answering CLUSTERDOWN to keyed commands	stuck	stuck	stuck

• On 1.3.0 the replay fails with the same found 2 shards error as stage, so it reproduces the incident.
• No client can handle the last row: if MemoryDB's promoted node isn't serving yet, nothing is. The stage capture below rules it in or out.

Tests

• ./gradlew :lib-jedis-pool:test: 39 of 39 pass, including the existing Testcontainers failover (Redis 7.2) and the hardened-user tests (NOPERM on the probe key is still reported).
• Run locally, not committed: the same failover scenarios against real redis:7.2 and valkey:8.0 containers (graceful, paused + takeover, stopped + takeover, old primary rejoining, 20 concurrent threads). This PR passes all of them on both servers: 11–12 ms from promotion to the first write, about 1 s when the dead node hangs (one connect timeout), and no failed write while the old primary rejoins. 1.3.0 and [release] fix(lib-jedis-pool): stay connected through a MemoryDB failover that lists the failed primary as an extra shard (1.3.1) #149 also pass these, because neither server produces MemoryDB's extra shard.

To verify on stage

• TLS: the port a replica reports in MOVED must be the one the client connects on. With TLS, Redis reports the TLS port to TLS clients, but this needs checking on MemoryDB.
• The extra shard: repeat the forced failover with a capture of CLUSTER SHARDS and the probe on each node every 0.5 s, to see the real reply and confirm the promoted node serves keyed commands.

Trade-off

The check that refused a multi-shard cluster ran on every rediscovery; it is gone. A multi-shard cluster is now caught only by its symptoms: keys outside the primary's shard fail with MOVED. The README already documents single-shard as a constraint. If we want the guard back, it fits as a one-time startup check, outside the recovery path.

Fixes #148. Alternative to #149: merge one of the two.

🤖 Generated with Claude Code

[jonmarti]

@pditommaso, approving: this is the better fix for #148, and I'll close #149 in its favour. Not reading the topology removes the dependency on MemoryDB's CLUSTER SHARDS reply, which we never captured, and the replay that reproduces the stage failure on 1.3.0 is a stronger test than the unit tests in #149. Three non-blocking notes inline. On the table: the third row (both entries owning every slot) can't come from open-source Redis, where each slot has a single owner in a node's view, but we can't rule it out for MemoryDB, which is the case for not reading it at all.