[jonmarti]

Summary

With redis.mode=cluster-primary, a service stays connected to Redis through a MemoryDB failover. It reconnects as soon as MemoryDB has promoted the replica, instead of minutes later. Fixes #148, COMP-2823.

In a forced failover of sched's stage MemoryDB cluster, MemoryDB had a new primary after 40 s, but sched stayed disconnected for about 4 more minutes. Primary discovery rejected the promoted primary's CLUSTER SHARDS reply because it listed 2 shards: the failed primary appears as a shard of its own, with no slots, while MemoryDB recovers it. During that time every Redis-backed path in sched failed, and its API answered 401 to every authenticated call.

Change

• Multi-shard check: only shards that own slots count. A reply where two or more shards own slots is still refused.
• Candidates: the online primaries of every entry, those of the shard that owns the slots first, each confirmed with the existing probe.
• Diagnostics: discovery errors carry a one-line summary of the reply, and the "Redis cluster primary is …" log line includes it when the reply lists more than one shard.

Why not simply drop the entries that own no slots: Redis 7.2 also reports the shard with no slots right after a takeover. Dropping them makes the existing failover integration test (should follow the primary across a failover) fail.

Tests

• New unit tests:
  • the MemoryDB reply, with the failed primary reported as failed and as still online;
  • the Redis 7.2 reply (one shard listed with no slots);
  • slots split across shards (still refused, with the reply in the error);
  • no online primary (the error includes the reply).
• The MemoryDB test fails on the previous code with requires a single-shard cluster - found 2 shards. The Redis 7.2 test and the failover integration test fail if slotless entries are dropped.
• ./gradlew :lib-jedis-pool:test: 43 of 43 pass.

Not included

• No integration test for MemoryDB's exact reply. Open-source engines don't produce it: Redis 7.2, Valkey 7.2 and Valkey 8.0 all report one shard during a takeover. The unit test reproduces the shape inferred from sched's logs, which only recorded the count.
• Verification on stage: after release, sched bumps lib-jedis-pool and the forced failover on stage is repeated. The new log line will show MemoryDB's actual reply.
• The 401 sched returns while Redis is unreachable: a separate sched issue.

🤖 Generated with Claude Code

[pditommaso]

An alternative to this PR is open: #150. Instead of reading MemoryDB's CLUSTER SHARDS reply, it finds the primary by probing each node of the discovery endpoint and following a replica's MOVED.

• Works whatever the extra shard holds: in a replay of the stage failover, this PR stays stuck when the failed primary is still listed as owning the slots. #150 recovers in that case too.
• CLUSTERDOWN is skipped: confirmPrimary here only catches JedisConnectionException. So when the old primary returned and answered CLUSTERDOWN (stage, 12:51:30), discovery stopped trying the rest of that node's candidates.

Both PRs bump to 1.3.1, so only one should be merged. The comparison table is in the #150 description.

[jonmarti]

@pditommaso, closing in favour of #150: finding the primary by probing doesn't depend on MemoryDB's CLUSTER SHARDS reply, which we never captured.