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.

Comienza con el handler proporcionado y el Subgraph de ejemplo que registra el primer campo nulo; después, inspecciona cómo graph-node rellena los valores de ethereum.TransactionReceipt a partir de datos RPC de Ethereum. Reproduce el problema en Görli y compara los deployments; se considera terminado cuando los campos de receipt se comporten de forma consistente o cuando su comportamiento nullable y no determinista se gestione explícitamente.