Interface RequestErrorContext

The 1-based attempt that failed.

Whether the failure surfaced because the per-window retry budget was exhausted: the failure was retryable, but the window's retry spend was already spent, as opposed to a failure that was never retryable. Present only on the terminal onError report of a budget-gated failure, so hook-based monitoring can detect chronic budget exhaustion (the condition the budget exists to surface) without polling transport-state snapshots.

The stable code of the normalized failure; see AniLinkErrorCode.

The upstream host scope the circuit breaker fast-failed for, present on CIRCUIT_OPEN_ERROR error contexts so fast-fail volume can be graphed per upstream directly from onError events.

The HTTP method of the request.

The delay before the next retry, when the failure will be retried.

Rate-limit accounting parsed from the failure response's x-ratelimit-* headers, when the upstream included them.

Library-generated correlation ID identifying one logical request across all of its attempts. Use it to join onRequestStart, onResponse, onError, and onRetry events for the same request in a metrics or logging backend.

Cooldown remaining on the open circuit breaker, in milliseconds, present on CIRCUIT_OPEN_ERROR error contexts while the breaker is open and no probe is pending, the answer to "when can I retry?" in the structured payload instead of the message prose.

Total time this logical request has spent waiting between attempts (retry backoff and server-dictated delays), accumulated across its attempts. Present only when a wait occurred, the same optional-presence convention as pacedMs on onResponse, so a request that failed after several server-dictated 429 delays stays distinguishable from a fast validation failure in error dashboards without joining onRetry events per requestId.

The HTTP status when the failure came from an API response.

The URL the request was sent to.