Skip to content

PollingConfig

Defined in: utils/polling.ts:35

optional context: string

Defined in: utils/polling.ts:45

Logical operation name used in log messages for identifying the polling context.

Used to distinguish between different polling operations in console output. Choose descriptive names that help with debugging and monitoring.

"operation"
"sign-transaction", "document-upload"

optional logPrefix: string

Defined in: utils/polling.ts:56

Custom prefix prepended to all log messages from this polling strategy.

Allows filtering and identifying logs specific to this polling instance. Useful when running multiple polling operations concurrently.

"[Polling]"
"[PaymentPolling]", "[TransactionPolling]", "[SignerPolling]"

optional fastAttempts: number

Defined in: utils/polling.ts:68

Number of initial rapid polling attempts before transitioning to ramp phase.

During fast phase, polls occur at fastDelayMs intervals (plus jitter). Higher values = more aggressive initial polling for fast responses. Lower values = faster transition to exponential backoff.

10
5 (for slower operations), 15 (for very fast operations)

optional fastDelayMs: number

Defined in: utils/polling.ts:80

Base delay in milliseconds between polls during the fast phase.

This is the baseline interval before jitter is applied. Actual delay will vary by ±jitterRatio percentage. Lower values = more aggressive polling, higher network load.

100
50 (aggressive), 200 (conservative)

optional rampUntilMs: number

Defined in: utils/polling.ts:92

Duration threshold in milliseconds for the ramp phase.

While elapsed time < rampUntilMs, delay grows exponentially from fastDelayMs up to plateauDelayMs using a power curve (0.7 exponent). After this duration, polling enters plateau phase with constant delays.

20000 (20 seconds)
10_000 (faster transition), 30_000 (longer ramp for slow ops)

optional plateauDelayMs: number

Defined in: utils/polling.ts:104

Steady-state polling delay in milliseconds during plateau phase.

Once ramp phase completes, all subsequent polls use this interval (plus jitter). This is the “cruise speed” for long-running operations. Balance between responsiveness and network/resource efficiency.

5000 (5 seconds)
2_000 (more responsive), 10_000 (more efficient)

optional jitterRatio: number

Defined in: utils/polling.ts:117

Randomization ratio (0-1) for adding jitter to prevent thundering herd.

Jitter adds ±(ratio * delay) randomness to each polling interval. Higher values = more randomization, better distribution across time. Lower values = more predictable intervals, less variance. Prevents synchronized polling when multiple clients start simultaneously.

0.440% randomization)
0.220%, less jitter), 0.550%, more jitter)

optional maxLogIntervalMs: number

Defined in: utils/polling.ts:129

Maximum time in milliseconds between log outputs (heartbeat interval).

Forces a log message if this much time passes without logging, even if normal log throttling would suppress it. Prevents “silent” long-running operations; ensures monitoring visibility.

15000 (15 seconds)
10_000 (more frequent heartbeats), 30_000 (less verbose)

optional abortSignal: AbortSignal

Defined in: utils/polling.ts:148

External abort signal for graceful cancellation of polling operation.

When the signal is aborted, the polling strategy throws an error on the next poll attempt. Use AbortController to create signals. Allows coordinated cancellation across multiple async operations.

undefined (no external cancellation)
const controller = new AbortController();
const strategy = createPollingStrategy({
abortSignal: controller.signal
});
// Later: controller.abort();