@algorandfoundation/algokit-subscriber / types/subscription / AlgorandSubscriberConfig
types/subscription.AlgorandSubscriberConfig
Configuration for an AlgorandSubscriber.
CoreTransactionSubscriptionParams
↳ AlgorandSubscriberConfig
• Optional arc28Events: Arc28EventGroup[]
Any ARC-28 event definitions to process from app call logs
CoreTransactionSubscriptionParams.arc28Events
• filters: SubscriberConfigFilter<unknown>[]
The set of filters to subscribe to / emit events for, along with optional data mappers.
CoreTransactionSubscriptionParams.filters
• Optional frequencyInSeconds: number
The frequency to poll for new blocks in seconds; defaults to 1s
• Optional maxIndexerRoundsToSync: number
The maximum number of rounds to sync from indexer when using `syncBehaviour: ‘catchup-with-indexer’.
By default there is no limit and it will paginate through all of the rounds. Sometimes this can result in an incredibly long catchup time that may break the service due to execution and memory constraints, particularly for filters that result in a large number of transactions.
Instead, this allows indexer catchup to be split into multiple polls, each with a transactionally consistent boundary based on the number of rounds specified here.
CoreTransactionSubscriptionParams.maxIndexerRoundsToSync
• Optional maxRoundsToSync: number
The maximum number of rounds to sync from algod for each subscription pull/poll.
Defaults to 500.
This gives you control over how many rounds you wait for at a time,
your staleness tolerance when using skip-sync-newest or fail, and
your catchup speed when using sync-oldest.
CoreTransactionSubscriptionParams.maxRoundsToSync
• syncBehaviour: "skip-sync-newest" | "sync-oldest" | "sync-oldest-start-now" | "catchup-with-indexer" | "fail"
If the current tip of the configured Algorand blockchain is more than maxRoundsToSync
past watermark then how should that be handled:
skip-sync-newest: Discard old blocks/transactions and sync the newest; useful
for real-time notification scenarios where you don’t care about history and
are happy to lose old transactions.sync-oldest: Sync from the oldest rounds forward maxRoundsToSync rounds
using algod; note: this will be slow if you are starting from 0 and requires
an archival node.sync-oldest-start-now: Same as sync-oldest, but if the watermark is 0
then start at the current round i.e. don’t sync historical records, but once
subscribing starts sync everything; note: if it falls behind it requires an
archival node.catchup-with-indexer: Sync to round currentRound - maxRoundsToSync + 1
using indexer (much faster than using algod for long time periods) and then
use algod from there.fail: Throw an error.CoreTransactionSubscriptionParams.syncBehaviour
• Optional waitForBlockWhenAtTip: boolean
Whether to wait via algod /status/wait-for-block-after endpoint when at the tip of the chain; reduces latency of subscription
• watermarkPersistence: Object
Methods to retrieve and persist the current watermark so syncing is resilient and maintains its position in the chain
| Name | Type | Description |
|---|---|---|
get |
() => Promise<bigint> |
- |
set |
(newWatermark: bigint) => Promise<void> |
- |