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.

Bắt đầu với handler được cung cấp và Subgraph mẫu ghi lại trường null đầu tiên, sau đó kiểm tra cách graph-node điền các giá trị ethereum.TransactionReceipt từ dữ liệu RPC của Ethereum. Tái hiện sự cố trên Görli và so sánh các deployment; được xem là hoàn tất khi các trường receipt hoạt động nhất quán hoặc hành vi nullable và không xác định của chúng được xử lý một cách rõ ràng.