[automatic failover] Improve failover resilience by evaluating circuit breaker before retries

[ggivo]

Problem

Currently, the circuit breaker is evaluated only after all retry attempts are exhausted. This delays failover to healthy endpoints in unstable network conditions, as the system must wait for all retries to complete before marking an endpoint as unhealthy.

Solution

This PR changes the evaluation order so that the circuit breaker counts each connection error separately, even during retry attempts. This allows the circuit breaker to open more quickly when an endpoint is experiencing issues, enabling faster failover to healthy endpoints.

Changes

• Modified the order of evaluation between circuit breaker and retry mechanisms
• Added integration test to verify the new behavior

[Copilot]

Pull Request Overview

This PR reorders the circuit breaker and retry decorations so that each connection error immediately counts toward opening the circuit breaker, and adds an integration test to verify the new behavior.

• Swap retry and circuit breaker in CircuitBreakerCommandExecutor to evaluate the circuit breaker before retry attempts.
• Add an integration test (testCircuitBreakerCountsEachConnectionErrorSeparately) to validate per-attempt error counting and faster failover.
• Adjust the formatter-maven-plugin version in the POM.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/main/java/redis/clients/jedis/mcf/CircuitBreakerCommandExecutor.java	Move withCircuitBreaker ahead of withRetry so the circuit breaker triggers before retrying
src/test/java/redis/clients/jedis/failover/FailoverIntegrationTest.java	Add integration test covering the new circuit breaker behavior under retry scenarios
formatter-pom.xml	Change formatter-maven-plugin version from 2.23.0 to 2.16.0

Comments suppressed due to low confidence (4)

src/main/java/redis/clients/jedis/mcf/CircuitBreakerCommandExecutor.java:38

• [nitpick] Consider adding a brief comment explaining why the retry decorator was moved below the circuit breaker to clarify the execution order for future maintainers.

supplier.withCircuitBreaker(cluster.getCircuitBreaker());

src/main/java/redis/clients/jedis/mcf/CircuitBreakerCommandExecutor.java:39

• Add a unit test specifically for CircuitBreakerCommandExecutor to confirm that the circuit breaker is evaluated before retry logic, ensuring this new order is exercised and protected against regressions.

supplier.withRetry(cluster.getRetry());

formatter-pom.xml:23

• [nitpick] Verify that downgrading the formatter-maven-plugin is intentional and compatible with your formatter rules; consider aligning to the latest stable plugin to benefit from fixes.

<version>2.16.0</version>

src/test/java/redis/clients/jedis/failover/FailoverIntegrationTest.java:289

• [nitpick] The inline comment for the failure rate threshold is split across multiple lines; consider consolidating it into a single, clear comment to improve readability.

.circuitBreakerFailureRateThreshold(50) // 50% failure

[atakavci]

so what is the issue with 2.23 ?

[ggivo]

@atakavci
2.23 requires Java 11.
There is a slight difference in the formatted code if we format the code using 2.23.0 vs 2.16.0 (used in the pom.xml with regular build).
To avoid the difference decided to align the versions.

[atakavci]

LGTM