int failures = getFailureCount(handle);

        // Base interval starts at 1 second, increases with failures
        // Max interval is 30 seconds for inactive directories
        return Math.min(MAX_POLL_INTERVAL, BASE_POLL_INTERVAL + (failures * 2000));
    }

    /**
     * Get failure count for a handle
     *
     * @param handle notification handle

                    // Exponential backoff on errors: max 30 seconds, based on consecutive failures
                    try {
                        int failures = Math.min(registration.getHeartbeatFailures(), MAX_FAILURE_LIMIT);
                        long backoffDelay = Math.min(MAX_ERROR_BACKOFF, BASE_ERROR_DELAY * (1L << failures));
                        Thread.sleep(backoffDelay);

      description: |
        Please only use this template for submitting reports about flaky tests or jobs (pass or fail with no underlying change in code) in Kubernetes CI.
        Links to go.k8s.io/triage and/or links to specific failures in spyglass are appreciated.
        Please see the deflaking doc (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-testing/flaky-tests.md) for more guidance.
    validations:
      required: true

| `minio_cluster_replication_proxied_head_requests_failures` | (_Site Replication Only_)Number of failures in HEAD requests proxied to replication target                          |

| `minio_cluster_erasure_set_read_tolerance`       | Number of drive failures that can be tolerated without disrupting read operations. <br><br>Type: gauge  | `pool_id`, `set_id` |
| `minio_cluster_erasure_set_write_tolerance`      | Number of drive failures that can be tolerated without disrupting write operations. <br><br>Type: gauge | `pool_id`, `set_id` |

            if (transport.isFailed()) {
                return true;
            }

            // Check for consecutive failures
            String key = getConnectionKey(transport);
            AtomicInteger failures = consecutiveFailures.get(key);
            if (failures != null && failures.get() >= MAX_CONSECUTIVE_FAILURES) {
                Long lastFailure = lastFailureTimes.get(key);

    @Test
    @DisplayName("Test mixed success and failure pattern")
    void testMixedPattern() throws Exception {
        // Success
        circuitBreaker.call(() -> "success");

        // Two failures (not enough to open)
        for (int i = 0; i < 2; i++) {
            try {
                circuitBreaker.call(() -> {
                    throw new RuntimeException("Test failure");
                });

        return EventListener.NONE;
      }
    }
  };

  ...
}
```

### Events with Failures

When an operation fails, a failure method is called. This is `connectFailed()` for failures while building a connection to the server, and `callFailed()` when the HTTP call fails permanently. When a failure happens it is possible that a `start` event won’t have a corresponding `end` event.

 * of SSO authentication and authorization processes. It extends FessSystemException
 * to provide consistent error handling within the Fess system for SSO-related
 * processing failures such as token validation errors, communication failures
 * with SSO providers, or configuration issues.
 */
public class SsoProcessException extends FessSystemException {

    private static final long serialVersionUID = 1L;

    /**

    /**
     * Gets the number of consecutive heartbeat failures.
     *
     * @return the number of consecutive heartbeat failures
     */
    public int getHeartbeatFailures() {
        return heartbeatFailures;
    }

    /**
     * Checks if this registration has expired based on the timeout.
     *
     * @param timeoutMs the timeout in milliseconds
     * @return true if the registration is expired
     */