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.

Beginne mit dem bereitgestellten Handler und dem Beispiel-Subgraph, der das erste Nullfeld erfasst, und untersuche anschließend, wie graph-node Werte von ethereum.TransactionReceipt aus Ethereum-RPC-Daten befüllt. Reproduziere das Problem auf Görli und vergleiche die Deployments; abgeschlossen ist die Aufgabe, wenn sich die Receipt-Felder konsistent verhalten oder ihr Nullable- und nichtdeterministisches Verhalten explizit behandelt wird.