OpenZeppelin / OpenZeppelin/Robust-Provider
`BlockNotFound` Might Not be Properly Returned When The Underlying Node is Not Reth/Anvil
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 6
- Forks
- 4
- Avg merge
- 15h 52m
- Merged PRs (30d)
- 5
Description
When a queried block is not found on-chain, the RobustProvider returns (or intends to) BlockNotFound error. This was done to avoid the ambiguity of alloy of just returning None.
The problem is that different Nodes have different behavior when querying for non-existent blocks:
- Anvil (dev node): Returns
None - Reth node: Returns
None - Geth node: Return an RPC error (exact error message to be determined)
- etc.
We need to have tests running on different nodes verifying that the expected behavior is present, i.e. whether alloy properly converts all Nodes' "block not found" particular errors/results into None (and by extension, that RP converts to BlockNotFound).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining RobustProvider's block query behavior and Alloy's handling of missing blocks. Run tests against Anvil, Reth, and Geth, including each node's non-existent-block response; done means all relevant responses consistently become None in Alloy and BlockNotFound in RobustProvider.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- blockchain
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100