jiangzho opened a new pull request, #806:
URL: https://github.com/apache/spark-kubernetes-operator/pull/806
### What changes were proposed in this pull request?
When ReconcilerUtils.getOrCreateSecondaryResource retries a failed
secondary-resource creation, it now honors the server's requested retry delay
instead of always using our own exponential backoff:
- BackoffUtils.getRetryAfterMillis reads
KubernetesClientException.getStatus().getDetails().getRetryAfterSeconds() — the
field the Kubernetes API server mirrors from the HTTP Retry-After header into
the response body (fabric8's client doesn't expose the raw header itself). When
present and positive, BackoffUtils.backoffSleep sleeps for exactly that
duration; otherwise it falls back to the existing jittered exponential backoff,
unchanged.
- ReconcilerUtils.shouldBackoffBeforeRetry now also returns true whenever a
Retry-After value is present, regardless of status code — previously only 409
and 429 triggered a backoff sleep, so a transient 503 carrying
retryAfterSeconds was retried immediately, ignoring the server's hint.
### Why are the changes needed?
The server is in the best position to say how long to wait before retrying
a throttled or overloaded request. Always using our own backoff schedule can
retry too
soon (extending throttling) or wait longer than necessary, and previously
we ignored the hint entirely for non-429/409 errors like 503.
### Does this PR introduce any user-facing change?
No.
### How was this patch tested?
Added BackoffUtilsTest covering getRetryAfterMillis
(present/absent/non-positive/no-status cases) and computeBackoffDelay bounds.
Added two tests in
ReconcilerUtilsTest: retriesCreateOn429AndSucceedsHonoringRetryAfter (429
with retryAfterSeconds=1) and
retriesCreateOnTransient5xxHonoringRetryAfterWhenPresent
(503 with retryAfterSeconds=1), both asserting the retry succeeds and
waited at least 1s.
### Was this patch authored or co-authored using generative AI tooling?
Co-Authored-by: Claude Code (claude-sonnet-5)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
