Support standbyok query parameter in Vault health checks to avoid HttpClient retry logging in HA deployments

[ptirador]

Problem

When using Spring Vault 3.2.0 with Vault in HA mode and Apache HttpClient 5.5.1+, health checks generate excessive log noise:

1. Spring Vault calls /v1/sys/health without query parameters
2. If Standby Vault nodes are hit, they return HTTP 429
3. Apache HttpClient 5.5.1+ logs retry attempts at INFO level (HTTPCLIENT-2371). Log example: ex-0000000043 https://<vault-url>:8200 responded with status 429; request will be automatically re-executed in 1 SECONDS (exec count 2)
4. This creates log noise on every health check cycle (typically every 5-10 seconds)

Context

The log noise was introduced when I upgraded my Spring Boot application from:

• Spring Boot 3.4.11 (HttpClient 5.4.4) → Spring Boot 3.5.8 (HttpClient 5.5.1+)

HttpClient 5.5.1 added explicit retry logging:

• Jira HTTPCLIENT-2371
• GitHub PR #674

While the health check correctly reports status as "UP", the 429 response triggers HttpClient's retry mechanism, logging each attempt.

Health check response

{
    "status": "UP",
    "components": {
        [...]
        "vault": {
            "status": "UP",
            "details": {
                "state": "Vault in standby",
                "version": "1.15.6"
            }
        }
    }
}

Example Logs

INFO o.a.h.c.h.i.c.HttpRequestRetryExec : ex-0000000042 https://<vault-url>:8200 responded with status 429; request will be automatically re-executed in 1 SECONDS (exec count 2)
INFO o.a.h.c.h.i.c.HttpRequestRetryExec : ex-0000000043 https://<vault-url>:8200 responded with status 429; request will be automatically re-executed in 1 SECONDS (exec count 2)

Proposed Solution
Add configuration properties to support Vault's HA query parameters:

# Option 1: Feature flags
spring.vault.health.standby-ok=true
spring.vault.health.perfstandby-ok=true

# Option 2: Generic query parameters
spring.vault.health.query-params=standbyok=true&perfstandbyok=true

This would make the health check call:

GET /v1/sys/health?standbyok=true&perfstandbyok=true

Benefits

• Eliminates log noise - Standby nodes return 200, no retries needed
• More semantically correct - 200 response better represents healthy standby state
• Improves observability - Real issues won't be hidden in retry noise

[mp911de]

Have you actually considered reaching out to the Vault team that Status 429 Too Many Requests isn't the appropriate one for what they are trying to express? Trying to make use of retry logic within HTTP clients for 429 seems a smart idea, that can work for retries without the need to touch a client or application, but it also creates a false assumption for components that deliberately react to 429.

Additionally logging of a commonly used status by the Apache HTTP Client is questionable at best, we already experience initial fallout for Vault users. In other scenarios, where services use rate limiting, applications will see a much larger effect of log events.

To mitigate the issue, either apply configuration to your logging components or use a HttpClient instance with a tailored DefaultHttpRequestRetryStrategy implementation. Looking at the design of DefaultHttpRequestRetryStrategy, it is built in a way that requires a subclass to configure retryable status codes.

Another approach is to use a gateway/load balancer in front of Vault that routes calls to active nodes only.

That being said, updating Spring Vault isn't appropriate.