@btx-tools SDK — BTX service-challenge admission control
    Preparing search index...

    Retry configuration for BtxChallengeClient.call.

    Default { max: 0 } — opt-in. Retries fire only on transient failures: network errors (DNS/TCP/TLS) and 5xx HTTP responses. Never retries on 4xx HTTP, JSON-RPC error envelopes, parse errors, or timeouts — those are deterministic failures where another attempt won't help.

    Exponential backoff: delay between attempt N and N+1 is baseDelayMs * 2^(N-1). With jitter: true, adds random(0, baseDelayMs).

    Audit ref: D-3 in BTX/audits/btx-challenges-sdk-audit-2026-05-22.md.

    interface RetryOptions {
        baseDelayMs?: number;
        jitter?: boolean;
        max: number;
        onRetry?: (attempt: number, error: unknown, nextDelayMs: number) => void;
    }
    Index

    Properties

    baseDelayMs?: number

    Base delay in ms between attempts. The actual delay between attempt N and N+1 is baseDelayMs * 2^(N-1), capped at 60 s so a high max doesn't schedule delays past the process lifetime. Default 500 ms.

    jitter?: boolean

    If true, adds random(0, baseDelayMs) of jitter to each delay. Default false. The 60 s cap (see baseDelayMs) is applied after jitter, so the delay slept — and the value passed to onRetry — never exceeds 60 s.

    max: number

    Maximum number of retry attempts (in addition to the initial call). 0 disables retry. Non-integer / negative / NaN values are clamped to 0.

    onRetry?: (attempt: number, error: unknown, nextDelayMs: number) => void

    Observability hook fired once per scheduled retry, before the backoff sleep, with the exact delay (post-jitter) about to be slept.

    • attempt — 1-indexed retry number (1 = first retry after the initial call).
    • error — the retryable error from the just-failed attempt (a BtxError subclass: BtxNetworkError or BtxHttpError for a 5xx).
    • nextDelayMs — the precise delay (including jitter) about to be slept.

    Fires only for retryable failures — non-retryable errors throw before the next attempt is scheduled, so the hook never sees them. If the caller's AbortSignal fires during the subsequent backoff sleep, the retry is still abandoned (the hook reports intent-to-retry, not success). Keep the callback cheap and non-throwing: an exception thrown inside onRetry propagates out of the client call.

    Audit ref: L-3 in BTX/audits/btx-challenges-sdk-audit-2026-05-23.md.