Inconsistently Null `ethereum.TransactionReceipt` Fields

I wanted to report some inconsistencies that I found with ethereum.TransactionReceipt fields. Specifically, fields that are supposed to be non-null (as defined in @graphprotocol/graph-ts) are sometimes null.

So far, I have seen this for contractAddress and root fields.

I had originally debated reporting this in the graph-ts repo (as I though that changing the type of contractAddress: Bytes | null), but decided to instead report it here because these fields appear to be null pretty randomly.

What is the current behavior?

You can fairly easily reproduce this with a similar handler:

import { log, ethereum } from "@graphprotocol/graph-ts";

export function handleEvent(event: ethereum.Event): void {
  if (event.receipt) {
    log.warning(
      "contract address: {}",
      [event.receipt!.contractAddress.toHexString()],
    );
  }
}

This will randomly error out because the contractAddress field will be null:

Handler skipped due to execution failure, error: Tried to read AssemblyScript value that is 'null'. Suggestion: look into the function that the error happened and add 'log' calls till you find where a 'null' value is being used as non-nullable. It's likely that you're calling a 'graph-ts' function (or operator) with a 'null' value when it doesn't support it. wasm backtrace: 0: 0x2d05 - <unknown>!src/graph-token/handleTransfer , handler: handleTransfer

I also wrote a sample Subgraph that, when deployed to Subgraph Studio (on Görli, I did not try on Mainnet), will observe this issue. The Subgraph will just record the first time it runs into a null field on the ethereum.TransactionReceipt that gets passed in. Re-deploying this Subgraph to the Studio will cause the first time that a null field be observed to change (it typically happens close to latest).

What is the expected behavior?

Consistent behaviour for ethereum.TransactionReceipt. Subgraphs that depend on event.receipt.contractAddress field for example are almost guaranteed to not be deterministic across deployments (since the field will be null randomly - usually closer to latest block).

My guess is that this is an issue with Ethereum RPC returning inconsistent data. Maybe the best that can be done is to flag some of these fields as "non-deterministic" (kind of like how IPFS was handled).

Additional Notes:

I also noticed that receipt can be null sometimes. It appears to be consistent though - but I found it surprising.

提供されたhandlerと、最初のnullフィールドを記録するサンプルSubgraphから始め、その後、graph-nodeがEthereum RPCデータからethereum.TransactionReceiptの値をどのように設定するかを調査します。Görliで問題を再現し、deploymentsを比較します。完了の条件は、receiptフィールドが一貫して動作するか、nullableおよび非決定的な動作が明示的に処理されていることです。