Ethereum Transaction Receipts in Event Handlers

[tilacog]

This PR allows Ethereum event handlers to access the receipt for the transaction which emitted it.

To support this, we introduce:

• a new type hierarchy to the runtime
• a new specVersion: 0.0.6
• a new apiVersion: 0.0.7

1. Usage in Mappings

An event handler will receive an Event containing a receipt whenever it is declared in the subgraph manifest with the new receipt: true key, which is optional and defaults to false.

eventHandlers:
  - event: NewGravatar(uint256,address,string,string)
    handler: handleNewGravatar
    receipt: true

Inside the handler function, the receipt can be accessed in the Event.receipt field.
When the receipt key is set to false or omitted in the manifest, a null value will be returned instead.

2. New runtime data types

_	Type	Description
A	AscEthereumEventWithReceipt	Contains all data for a Event plus a non-nullable receipt field, containing [B]
B	AscEthereumTransactionReceipt	A receipt for the transaction that emitted this event, which contains a logs field with an array of [C], containing all the logs for the associated transaction.
C	AscEthereumLog	A log from an event emitted within the transaction.

Depending on the subgraph manifest configuration, the runtime will receive either an AscEthereumEvent or an AscEthereumEventWithReceipt.

3. Receipt Ingestion

Transaction receipts will be collected inside the blocks_with_triggers function (which is used by PoolingBlockStream) only when an EthereumLogFilter requires them.

4. Affected Structs and Enums

The following items were updated with optional fields to accommodate data for receipt themselves and their requirement flags :

• MappingEventHandlergot a new receipt: bool field which defaults to false when deserializing, to account for omissions in the subgraph manifest.
• EthereumLogFilter: its inner Graph data structure was updated so its edges represent the requirement of a receipt. The original HashSet<EventSignature> of wildcard events was also updated to a HashMap<EventSignature, bool> to reflect that same aspect.
• EthereumTrigger::Log variant got a second Option<web3::TransactionReceipt> field
• MappingTrigger::Log variant got a new receipt: Option<web3::TransactionReceipt> field

Todo:

• validations for the new apiVersion
• tests for EthereumLogFilter
• add a retry strategy to the get_transaction_receipts_for_transaction_hashes function
• graph-ts and graph-cli released (see "Dependencies" below)
• docs

Resolves #3218

---

Dependencies

This PR depends on:

• Allow event handlers to require transaction receipts graph-tooling#860
• Introduce TransactionReceipt and Log graph-ts#260

[evaporei]

Another couple of things:

1. Any reason for this PR still being Draft instead of Ready for Review?
2. This needs a rebase, there are conflicts still.

[tilacog]

Another couple of things:

1. Any reason for this PR still being Draft instead of Ready for Review?

The Draft status is related to the dependent PRs not being merged, but I can change it now since we already started the review process.

[tilacog]

Rebased with latest main branch

[evaporei]

💯

[franz101]

You are my hero @tilacog

[creaink]

Add receipt: true caused: Failed to deploy to Graph node https://api.thegraph.com/deploy/: ipfs failure::failure parsing subgraph manifest. when run graph deploy since today. Is there any changed?

[azf20]

hi @creaink this is an issue with deployments to the Hosted Service, we are investigating and expect to resolve soon, sorry for the trouble