What's new

• When scanning for triggers, the blocks interval to be fetched in a single request is partitioned into smaller-size lightweight RPC queries to be sent in parallel to the chain provider. This leverages the case when the provider is proxying multiple blockchain nodes that can serve the requests simultaneously.
• The fetch-and-process cycle, previously sequential, has been extended to ask for 'future' blocks (to be processed on the next iteration) in the background, making them immediately available when the processing of the current batch has finished and have to advance to a new one.

Upgrade notes

• The adaptive number of blocks to scan on the current iteration is divided into equal intervals of a fixed size given by a new environment variable GRAPH_SCAN_LOGS_RANGE_SIZE (defaults to 500).
• The number of pre-fetched blocks is always equal to the current adaptive range, however there is configurable maximum number of RPC requests that can be sent at once given by a new environment variable GRAPH_SCAN_LOGS_MAX_CONCURRENT_RPC (defaults to 10). Therefore, the maximum number of blocks that will be actually fetched concurrently to the processing of the current batch is 500 * 10, the rest of them being fetched synchronously on next iteration.

Performance improvements

• The syncing time for subgraphs having few triggers will be reduced multiple times while for others the time cost for fetching blockchain data will be included into the time cost of processing events into entities.