@algorandfoundation/algokit-subscriber / types/subscription / TransactionSubscriptionParams
types/subscription.TransactionSubscriptionParams
Parameters to control a single subscription pull/poll.
CoreTransactionSubscriptionParams
↳ TransactionSubscriptionParams
• Optional arc28Events: Arc28EventGroup[]
Any ARC-28 event definitions to process from app call logs
CoreTransactionSubscriptionParams.arc28Events
• Optional currentRound: bigint
The current tip of the configured Algorand blockchain. If not provided, it will be resolved on demand.
• filters: NamedTransactionFilter[]
The filter(s) to apply to find transactions of interest. A list of filters with corresponding names.
Example
filter: [{
name: 'asset-transfers',
filter: {
type: TransactionType.axfer,
//...
}
}, {
name: 'payments',
filter: {
type: TransactionType.pay,
//...
}
}]
CoreTransactionSubscriptionParams.filters
• 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
• watermark: bigint
The current round watermark that transactions have previously been synced to.
Persist this value as you process transactions processed from this method to allow for resilient and incremental syncing.
Syncing will start from watermark + 1.
Start from 0 if you want to start from the beginning of time, noting that
will be slow if onMaxRounds is sync-oldest.