PollingConfig
Defined in: core/src/utils/polling.ts:61
Properties
Section titled “Properties”context?
Section titled “context?”
optionalcontext?:string
Defined in: core/src/utils/polling.ts:71
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.
Default
Section titled “Default”"operation"Example
Section titled “Example”"sign-transaction", "document-upload"logPrefix?
Section titled “logPrefix?”
optionallogPrefix?:string
Defined in: core/src/utils/polling.ts:82
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.
Default
Section titled “Default”"[Polling]"Example
Section titled “Example”"[PaymentPolling]", "[TransactionPolling]", "[SignerPolling]"fastAttempts?
Section titled “fastAttempts?”
optionalfastAttempts?:number
Defined in: core/src/utils/polling.ts:94
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.
Default
Section titled “Default”10Example
Section titled “Example”5 (for slower operations), 15 (for very fast operations)fastDelayMs?
Section titled “fastDelayMs?”
optionalfastDelayMs?:number
Defined in: core/src/utils/polling.ts:106
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.
Default
Section titled “Default”100Example
Section titled “Example”50 (aggressive), 200 (conservative)rampUntilMs?
Section titled “rampUntilMs?”
optionalrampUntilMs?:number
Defined in: core/src/utils/polling.ts:118
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.
Default
Section titled “Default”20000 (20 seconds)Example
Section titled “Example”10_000 (faster transition), 30_000 (longer ramp for slow ops)plateauDelayMs?
Section titled “plateauDelayMs?”
optionalplateauDelayMs?:number
Defined in: core/src/utils/polling.ts:130
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.
Default
Section titled “Default”5000 (5 seconds)Example
Section titled “Example”2_000 (more responsive), 10_000 (more efficient)jitterRatio?
Section titled “jitterRatio?”
optionaljitterRatio?:number
Defined in: core/src/utils/polling.ts:143
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.
Default
Section titled “Default”0.4 (±40% randomization)Example
Section titled “Example”0.2 (±20%, less jitter), 0.5 (±50%, more jitter)maxLogIntervalMs?
Section titled “maxLogIntervalMs?”
optionalmaxLogIntervalMs?:number
Defined in: core/src/utils/polling.ts:155
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.
Default
Section titled “Default”15000 (15 seconds)Example
Section titled “Example”10_000 (more frequent heartbeats), 30_000 (less verbose)timeoutMs?
Section titled “timeoutMs?”
optionaltimeoutMs?:number
Defined in: core/src/utils/polling.ts:178
Longest time in milliseconds a single request is polled, counted from the first poll that finds it still pending.
Once it has passed, the next poll throws the SDK’s own timeout error (a
ProtocolError with TimeoutWaitingForResponseErrorCode, as
defaultStrategy() throws), which ends the polling and fails the call.
Without a limit, a request the network never picked up stays unknown
and is polled for as long as the page is open.
A call that times out can still complete: a request the canister already received keeps running there. Check for its effect before retrying a call that must not run twice.
Each request has its own limit, so a strategy shared by many calls never
runs out. Pass Infinity to poll until the request settles or
abortSignal fires.
Default
Section titled “Default”300000 (5 minutes, the SDK’s defaultStrategy() limit)
Example
Section titled “Example”60_000 (fail faster), Infinity (no limit)abortSignal?
Section titled “abortSignal?”
optionalabortSignal?:AbortSignal
Defined in: core/src/utils/polling.ts:199
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. The signal stops every request this strategy polls; to cancel a single call, give that call a strategy of its own.
Default
Section titled “Default”undefined (no external cancellation)Example
Section titled “Example”const controller = new AbortController();const strategy = createPollingStrategy({ abortSignal: controller.signal});// Later: controller.abort();