Computes the delay before the next retry, or null when the request must
surface the failure instead. Four gates run before the per-error-class
matrix in getRetryDelay: a failed half-open probe surfaces
immediately (retrying would fast-fail against the still-open breaker), a
disabled policy never retries, an exhausted retry budget surfaces the
failure without spending another retry, and a server-dictated delay (a
Retry-After header, or the rateLimit.reset metadata carried by both
HTTP-level and GraphQL-envelope 429s) longer than the budget window's
remaining time surfaces the failure instead of sleeping past the window
the budget was configured to bound.
The window gate applies only to server-dictated delays, the only
candidate delays that can park a caller for up to a full minute per
retry. Client-chosen jittered backoff delays are never gated by the
window: they are already bounded by the policy's maxDelayMs cap, so they
cannot stretch one window's retry spend across many minutes of
wall-clock waits. The gate compares the un-clamped server-dictated
deadline (see getUnclampedRetryAfterDelay and
getUnclampedRateLimitResetDelay): a delay that outlasts
the window surfaces immediately, instead of retrying into repeated
clamped 60-second hops that each spend a budget unit. Like the count gate,
the window gate requires both halves of the budget (the live state and
the configuration) and spends no budget unit when it surfaces the
failure.
Computes the delay before the next retry, or
nullwhen the request must surface the failure instead. Four gates run before the per-error-class matrix in getRetryDelay: a failed half-open probe surfaces immediately (retrying would fast-fail against the still-open breaker), a disabled policy never retries, an exhausted retry budget surfaces the failure without spending another retry, and a server-dictated delay (aRetry-Afterheader, or therateLimit.resetmetadata carried by both HTTP-level and GraphQL-envelope 429s) longer than the budget window's remaining time surfaces the failure instead of sleeping past the window the budget was configured to bound.The window gate applies only to server-dictated delays, the only candidate delays that can park a caller for up to a full minute per retry. Client-chosen jittered backoff delays are never gated by the window: they are already bounded by the policy's
maxDelayMscap, so they cannot stretch one window's retry spend across many minutes of wall-clock waits. The gate compares the un-clamped server-dictated deadline (seegetUnclampedRetryAfterDelayandgetUnclampedRateLimitResetDelay): a delay that outlasts the window surfaces immediately, instead of retrying into repeated clamped 60-second hops that each spend a budget unit. Like the count gate, the window gate requires both halves of the budget (the live state and the configuration) and spends no budget unit when it surfaces the failure.