Package io.vrap.rmf.base.client.http

Class RetryAfterDelay

java.lang.Object

io.vrap.rmf.base.client.http.RetryAfterDelay

public final class RetryAfterDelay
extends Object

Method Summary

Modifier and Type	Method	Description
static boolean	canRetryWithin(ApiHttpException exception, long maxDelayMillis)
static boolean	canRetryWithin(ApiHttpHeaders headers, int statusCode, long maxDelayMillis)	Whether a rate-limited response can usefully be retried within the configured maximum delay.
static Duration	forContext(dev.failsafe.ExecutionContext<ApiHttpResponse<byte[]>> context, long initialDelayMillis, long maxDelayMillis)
static boolean	hasTiming(ApiHttpException exception)
static boolean	hasTiming(ApiHttpHeaders headers, int statusCode)
static Optional<Duration>	of(ApiHttpException exception, Instant now)
static Optional<Duration>	of(ApiHttpHeaders headers, int statusCode, Instant now)
static Optional<Duration>	parse(String value, Instant now)

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Method Details

parse

public static Optional<Duration> parse(@Nullable
 String value,
 Instant now)

of

public static Optional<Duration> of(@Nullable
 ApiHttpHeaders headers,
 int statusCode,
 Instant now)

hasTiming

public static boolean hasTiming(@Nullable
 ApiHttpHeaders headers,
 int statusCode)

of

public static Optional<Duration> of(@Nonnull
 ApiHttpException exception,
 Instant now)

hasTiming

public static boolean hasTiming(ApiHttpException exception)

canRetryWithin

public static boolean canRetryWithin(@Nullable
 ApiHttpHeaders headers,
 int statusCode,
 long maxDelayMillis)

Whether a rate-limited response can usefully be retried within the configured maximum delay.

A rate limit window is a hard boundary: until it resets, every request is rejected. So if the server asks for longer than we are willing to wait, capping the delay does not salvage the retry — it guarantees the next attempt lands inside the same window and fails again, and the one after that, until the budget is gone. The caller ends up waiting maxRetries * maxDelay and still gets the error, having added load to a server that was already shedding it.

Failing immediately is more useful: the caller gets the 429 straight away and can decide what to do with it, rather than being blocked on attempts that cannot succeed.

This applies to 429 only. A Retry-After on a 503 is the server's estimate of when it might recover, not a hard boundary, so an early retry there may well succeed and the delay is capped rather than abandoned.

Returns:

false when there is no timing header at all, or when the wait it asks for exceeds maxDelayMillis

canRetryWithin

public static boolean canRetryWithin(ApiHttpException exception,
 long maxDelayMillis)

See Also:

• canRetryWithin(ApiHttpHeaders, int, long)

forContext

public static Duration forContext(dev.failsafe.ExecutionContext<ApiHttpResponse<byte[]>> context,
 long initialDelayMillis,
 long maxDelayMillis)