Flag to skip RPC errors and continue Indexing

[anudit]

In case of FEVM, Some blocks of the full node snapshots have incomplete/no data which return a RPC erros like "Block was part of null round" & "Bad tipset with no Receipts" etc. I'd like to skip them so that the rest of the data can be indexed. The Graph has a similar feature https://thegraph.com/docs/en/developing/creating-a-subgraph/#non-fatal-errors

[0xOlias]

Thanks for opening this!

One idea - could this problem possibly be resolved by using a fallback RPC endpoint? AKA, if the primary provider/node doesn't have the block, check the next, and so on?

It would be pretty easy for Ponder to mark errors thrown within the user-provided event handler as non-fatal, but it would be pretty complicated to ignore RPC errors.

[anudit]

Making the rpcUrl in ResolvedPonderConfig.networks as an array would definitely be helpful in making indexing more stable, especially in cases where one RPC url might be rate limited.

Curious if it would be possible to mark rpc errors as non-fatal and continue indexing?

[0xOlias]

The complexity here is that Ponder internally keeps track of which block numbers/ranges have already been fetched & cached (for a specific set of contracts). This cache persists across hot reloads and redeploys.

So, if you want to ignore RPC errors, Ponder would have to do one of two things:

1. Mark the block number as cached, even though we don't have the block. This would leave the database in an "incorrect" state, because you don't know if that block actually contains logs that you care about.
2. Don't mark the block number as cached, but don't retry on failure. You would also need to update the logic that fetches logs from the database to ignore "gaps" in the cached block range (pretty big change).

One more question for you - do you know if these RPC errors only happen for old blocks? If they also happen for fresh blocks (in the unfinalized range), that would be very difficult to handle.

[anudit]

1. This might be useful flag to have like unstable_continue, something that explicitly states that the DB will be in an incorrect state.
2. Yeah I can understand this might be a big rewrite as we don't inherently expect that we would need to ignore blocks while indexing or will get incomplete data for.

So far it has only been in the past.

[0xOlias]

Ok, thanks for the response. I think an unstable_continue option is reasonable. I can add this to the roadmap alongside some general improvements I have planned for RPC error handling. Will update here with more details as they come.

[anudit]

Awesome, Looking forward to it.