`eth_call` via Graph Node returns "Required data unavailable"

[akshatmittal]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

anvil 0.2.0 (0688b5a 2024-02-06T00:22:52.883641000Z)

What command(s) is the bug in?

anvil --fork-url $rpc --chain-id 1 --no-rate-limit --prune-history

Operating System

Linux

Describe the bug

An eth_call from Graph Node returns with "Required data unavailable", screenshot attached.

The anvil node is forking mainnet using Infura as the provider (also tried Alchemy and LlamaRPC), graph-node is connected to this node via RPC and indexing a subgraph. This subgraph indexes fine against mainnet and used to index fine in this setup until a few weeks ago.

Zero idea on what could be causing this, any suggestions are appreciated and I'm willing to try any number of debug ops.

[onbjerg]

Not all RPC providers provide access to the full history, meaning only the last n blocks of historical data is available. This is most likely the case with the underlying RPC you are using, which causes this error.

[Evalir]

Indeed, as @onbjerg said make sure you're using an archive endpoint—else you won't have the required data.

[akshatmittal]

I tried it with Infura (Growth plan) and Alchemy (Scale plan) both with archive node capabilities (I can't seem to find any documentation saying that they limit archive data access). I also attempted to query a block from 2019, trace call on the tx mentioned and querying balance on genesis block on both providers and they both succeed.

Anything I should try with the RPCs or something else to verify if that's indeed the issue?

[onbjerg]

Interesting - what call is the indexer trying to perform, and at what block? I see some reference to PROPOSER_ROLE but I'm not really sure what this is referring to. Also, it would be preferred if you could post the logs as text in a codeblock so we can see it more clearly :)

[akshatmittal]

Sure, here's the log in plaintext: https://gist.github.com/akshatmittal/0f97e4fb4b5665df69438570f97b86ee (added some additional later errors, but I think they are all because of this one call failing)

Failing at block 16681681 and tx 0xf1bad (oh the irony), subgraph hash QmaYzfSaPsXEyueSVYqTXp4nYWTC8MxGazuZLqYVJnNhVD.

I'm not entirely sure what call exactly the indexer is making, to be honest. My understanding is that the indexer detects triggers using logs and then replays/traces the transaction to get more information to process it. The weirdest thing to me is certainly that the exact setup was working fine until just last week.

(I've also tried with --steps-tracing to see if that helps but same error)

[akshatmittal]

Quick update, just ran the exact same setup replacing anvil with hardhat and it works fine! This is certainly an issue with anvil based on everything I've tried at this point.

I've included additional logs from hardhat and infura RPCs to document what should happen here. https://gist.github.com/akshatmittal/0f97e4fb4b5665df69438570f97b86ee

I would really really like to get this running with anvil.

[akshatmittal]

Hey @onbjerg, @Evalir, I did some more debugging. Seems like this bug was introduced recently, I rolled back anvil version to nightly-8343e7d8ac08724238db1c014c325bba479ba587 and it works again!

My current best guess is that it was introduced in this commit d46bcb3 but I'm not certain.

Edit: Also, sidenote, the old version is much faster too when making calls.

[onbjerg]

@Evalir this is most likely because we are returning some optimism specific stuff in receipts even if we're not supposed to, wdyt?

[Evalir]

yep @onbjerg could be this. Will look into it

[akshatmittal]

I've nailed it down to the exact function call. Here's the code to reproduce: https://gist.github.com/akshatmittal/9fab55c38c75090fba173f4db058c394

Running against anvil node with command anvil --fork-url $rpc --chain-id 1 --no-rate-limit.

It should revert without reason but rather fails with "Required data unavailable".

[Evalir]

seems the repro is missing the ./setup.ts file