Block, transaction and call handlers

Until now, the only triggers for indexing were events. This release adds support for triggering based on blocks and transactions/calls in the form of blockHandlers and callHandlers (in addition to the existing eventHandlers).

From the documentation:

While events provide an effective way to collect relevant changes to the state of a contract, many contracts avoid generating logs to optimize gas costs. In these cases, a subgraph can subscribe to calls made to the data source contract. This is achieved by defining call handlers referencing the function signature and the mapping handler that will process calls to this function. To process these calls, the mapping handler will receive an EthereumCall as an argument with the typed inputs to and outputs from the call. Calls made at any depth in a transaction's call chain will trigger the mapping, allowing activity with the data source contract through proxy contracts to be captured.

Regarding block handlers:

In addition to subscribing to contract events or function calls, a subgraph may want to update its data as new blocks are appended to the chain. To achieve this a subgraph can run a function after every block or after blocks that match a predefined filter.

For more information about how to define and write call and block handlers, please refer to the documentation.

Note: This feature requires Parity archive nodes with the trace API enabled.

Adaptive block range scanning

In order to deal with Infura's limit of returning a maximum of 1000 matches for eth_getLogs, the block range based scanning for events is now adapting the size of the block ranges being scanned when necessary. After a problematic block range has been processed, the block range size returns to the original ETHEREUM_BLOCK_RANGE_SIZE value.

Efficient entityCount querying

Until now, querying the entityCount of a subgraph deployment via the subgraph of subgraphs at /subgraphs lazily counted the entities of the deployment. This becomes increasingly expensive as subgraphs grow in size.

Starting with this release, the entityCount is stored in the deployment and is updated whenever changes are made to the entities of the subgraph, including when operations are being reverted due to a block reorg. This makes querying entityCount efficient.

Other changes

• Use a global database lock to prevent Graph Nodes from running migrations in parallel (#922).
• Capture and log potential thread and database contentions (#917, #918, #921).
• Revert dynamically created data sources that are affected by block reorgs (#890, #907).
• Add log message codes to subgraph and query logs for analytics (#915).
• Hide URL passwords from logs (#849, #853).
• Remove subgraph_list JSON-RPC method (#899).