Skip to content

fix(anvil): return error for eth_getLogs with unknown blockHash instead of empty#14371

Merged
mattsse merged 1 commit intofoundry-rs:masterfrom
spalladino:fix/anvil-get-logs-unknown-block
Apr 20, 2026
Merged

fix(anvil): return error for eth_getLogs with unknown blockHash instead of empty#14371
mattsse merged 1 commit intofoundry-rs:masterfrom
spalladino:fix/anvil-get-logs-unknown-block

Conversation

@spalladino
Copy link
Copy Markdown
Contributor

Return a JSON-RPC error (-32000 "unknown block") when eth_getLogs is called with a blockHash that doesn't resolve to a known block, instead of silently returning an empty array. This aligns with how geth and other clients behave:

$ curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getLogs","params":[{"blockHash":"0x0000000000000000000000000000000000000000000000000000000000000001"}],"id":1}'  $RPC_URL

{"jsonrpc":"2.0","id":1,"error":{"code":-32000,"message":"unknown block"}}

$ curl -s -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"web3_clientVersion","params":[],"id":1}' $RPC_URL

{"jsonrpc":"2.0","id":1,"result":"Geth/v1.17.2-stable-be4dc0c4/linux-arm64/go1.26.1"}

See also paradigmxyz/reth#7371

Code written with Claude.

Match Geth's behavior by returning a JSON-RPC error (-32000 "unknown
block") when eth_getLogs is called with a blockHash that doesn't
resolve to a known block, instead of silently returning an empty
array.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@mattsse mattsse merged commit c81fa47 into foundry-rs:master Apr 20, 2026
16 checks passed
@github-project-automation github-project-automation Bot moved this to Done in Foundry Apr 20, 2026
@spalladino
Copy link
Copy Markdown
Contributor Author

spalladino commented Apr 20, 2026

Thank you all for the fast response 🚀

spalladino added a commit to AztecProtocol/aztec-packages that referenced this pull request Apr 21, 2026
When rolling back local L1 to L2 messages, we query each message against
L1 by fetching its log. Since #22154 (v5) this was done via blockHash.
However, querying logs by blockhash throws an RPC error if the block no
longer exists, which is likely if the local message was removed due to
an L1 reorg. We never hit this during testing because of
foundry-rs/foundry#14371.

To fix this, we know query by an L1 block number range. This also allows
to still find the locall message on L1 even if it was moved by a few
blocks due to a small reorg.

Additionally, this PR adds a fast-path in `rollbackL1ToL2Messages` that
matches the local rolling hash against the current remote state, so we
don't query by event when we don't need to.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

4 participants