Core - v1.3.1
    Preparing search index...

    Interface RetryOptions

    What one retried operation may override.

    Every field is optional. The attempt count and the backoff default to the delivery module, which systemDefaults registers with retries and retryBackoffMs, so a deployment tunes every retry in one place and a call site overrides only what is genuinely different about its operation.

    Declared beside Retry in core/ rather than in types/, because it names Logger, and the leaf layers do not import from core/.

    Bayu Dwiyan Satria

    1.3.1

    1.3.1

    interface RetryOptions {
        attempts?: number;
        backoffMs?: number;
        event?: string;
        logger?: Logger;
        isRetryable?(error: unknown): boolean;
    }
    Index
    attempts? backoffMs? event? logger?
    isRetryable?
    attempts?: number

    Total attempts, including the first. Anything below one is treated as one.

    delivery.retries + 1

    backoffMs?: number

    Delay before the second attempt, in milliseconds, doubling thereafter.

    delivery.retryBackoffMs

    event?: string

    The event name those lines carry.

    'retry'

    logger?: Logger

    Receives one warn line before each re-attempt.

    Omitted means retries are silent, which is rarely what an operator wants: a source that only succeeds on its third attempt looks healthy from the outside, and these lines are the only evidence that it is not.

    • Whether a given failure is worth another attempt.

      Parameters

      • error: unknown

      Returns boolean

      Replaces the default judgement rather than adding to it. A caller that only wants to refuse one more kind of failure should return false for it and defer to Retry.isRetryable for everything else.

      Retry.isRetryable

    Settings
    Member Visibility

    On This Page
    Properties
    Methods