RPC call getBlockByNumber behaves different than Ganache

[rhlsthrm]

Component

Anvil

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

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (e6f2bc6 2022-06-07T00:05:25.119456Z)

What command(s) is the bug in?

anvil

Operating System

Linux

Describe the bug

I'm trying to run a Graph node against a local Anvil instance in a docker compose setup. The Graph node errors with the following errors:

Jun 07 19:10:06.455 WARN Trying again after eth_getBlockByNumber(0, false) RPC call failed (attempt #10) with result Err(Decoder error: Error("invalid length 1, expected a (both 0x-prefixed or not) hex string with length of 16", line: 0, column: 0)), provider: mainnet-rpc-0

I investigated and I get an error if I call the JSON-RPC request against Anvil:

curl --request POST \
  --url http://localhost:8545/ \
  --header 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":[0,  false],"id":1}'

However, this works when the param "0" is a string.

In ganache-cli I can query with that same cURL and get a proper response. I'd like this functionality to be able to run full E2E tests using Anvil.

[mattsse]

following the spec the block parameter is either:

HEX String - an integer block number
String "earliest" for the earliest/genesis block
String "latest" - for the latest mined block
String "pending" - for the pending state/transactions

and with EIP-1898:

blockNumber: QUANTITY - a block number
blockHash: DATA - a block hash

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1898.md

however EIP-1898 does not cover eth_getBlockByNumber and doesn't list raw integers as supported

geth also does not like this:

{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"invalid argument 0: hex string without 0x prefix"}}

so not sure what to do, deviate from the spec and follow ganache or strict spec @gakonst ?

[rhlsthrm]

Hm, in this case, maybe it's a bug on Graph's end: https://github.com/graphprotocol/graph-node/blob/7182fc00b0a7a7bb07720abb157d6dce7d9ec074/chain/ethereum/src/ethereum_adapter.rs#L859

I don't speak Rust very well but it seems like it's passing a number in. I confirmed by trying with Ganache and it works. I will submit a bug to them.

[jakekidd]

According to ethereum wiki source here, under eth_getBlockByNumber:
https://eth.wiki/json-rpc/API

QUANTITY|TAG - integer of a block number, or the string "earliest", "latest" or "pending", as in the default block parameter.

So it seems to be a widespread assumption that an integer would be handled, even if it's not core geth behavior or covered in an EIP.

Keeping to the strict spec may be perfectly fine, but at the very least worth noting in the documentation as a "gotcha".

[carllippert]

Is there a work around for now?

[gakonst]

OK given this affects more people and the ecosystem's reliance on ganache's (wrong) implementation am convinced that it's OK to deviate from spec here.

Let's add a big fat warning in the code and try to get the graph to implement a proper fix so that it works with Geth.

[leoyvens]

Hi @gakonst, to make sure you're not following a red herring here, rust-web3 and therefore Graph Node do not submit requests with raw numbers, but always 0x prefixed hex numbers.

The Graph Node error says Decoder error: Error("invalid length 1, expected a (both 0x-prefixed or not) hex string with length of 16. So it seems to be having trouble decoding a field in the response.

[mattsse]

perhaps there are actually two issues here

• sending the requested blocknumber as integer
• something's not right in the response

just checked, this

curl --request POST \
  --url http://localhost:8545/ \
  --header 'content-type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":[0,  false],"id":1}'

actually has a different error response

{"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"invalid type: integer `0`, expected a string"}}

so currently no sure where The Graph Node error originates @rhlsthrm ?

@leoyvens

line: 0, column: 0 this looks like it's attempting to deserialize 0, so perhaps it doesn't even hit anvil in the first place and gets rejected in the graph (not familiar with the docker compose setup of OP )

also the Block type used by anvil or rather ethers-rs is identical to rust-web3

[rhlsthrm]

Hi @gakonst, to make sure you're not following a red herring here, rust-web3 and therefore Graph Node do not submit requests with raw numbers, but always 0x prefixed hex numbers.

The Graph Node error says Decoder error: Error("invalid length 1, expected a (both 0x-prefixed or not) hex string with length of 16. So it seems to be having trouble decoding a field in the response.

That's interesting. Any idea why it would be erroring here? I was unable to connect to an Anvil instance but I was able to connect to Ganache without any other setup changes.

not familiar with the docker compose setup of OP

This is the working docker-compose:

version: "3.8"

services:
  chain-1337:
    container_name: chain-1337-test
    image: trufflesuite/ganache-cli:latest
    command: "--chainId 1337 --mnemonic 'candy maple cake sugar pudding cream honey rich smooth crumble sweet treat' --hostname 0.0.0.0 --blockTime 3 --verbose"
    ports:
      - 8545:8545
    networks:
      - nxtp-test
  chain-1338:
    container_name: chain-1338-test
    image: trufflesuite/ganache-cli:latest
    command: "--chainId 1338 --mnemonic 'candy maple cake sugar pudding cream honey rich smooth crumble sweet treat' --host 0.0.0.0 --blockTime 3 --verbose"
    ports:
      - 8546:8545
    networks:
      - nxtp-test

  ######################

  graph-node-1337:
    container_name: graph-node-1337-test
    image: graphprotocol/graph-node:v0.25.0
    ports:
      - "8010:8000"
      - "8001:8001"
      - "8020:8020"
      - "8030:8030"
      - "8040:8040"
    depends_on:
      - ipfs
      - postgres-1337
      - chain-1337
    environment:
      postgres_host: postgres-1337
      postgres_user: graph-node
      postgres_pass: let-me-in
      postgres_db: graph-node
      ipfs: "ipfs:5001"
      ethereum: "mainnet:http://chain-1337:8545"
      GRAPH_LOG: info
    networks:
      - nxtp-test
  postgres-1337:
    container_name: postgres-1337-test
    image: postgres
    ports:
      - "5432:5432"
    command: ["postgres", "-cshared_preload_libraries=pg_stat_statements"]
    environment:
      POSTGRES_USER: graph-node
      POSTGRES_PASSWORD: let-me-in
      POSTGRES_DB: graph-node
    networks:
      - nxtp-test
  graph-node-1338:
    container_name: graph-node-1338-test
    image: graphprotocol/graph-node:v0.25.0
    ports:
      - "9010:8000"
      - "9001:8001"
      - "9020:8020"
      - "9030:8030"
      - "9040:8040"
    depends_on:
      - ipfs
      - postgres-1338
      - chain-1338
    environment:
      postgres_host: postgres-1338
      postgres_user: graph-node
      postgres_pass: let-me-in
      postgres_db: graph-node
      ipfs: "ipfs:5001"
      ethereum: "mainnet:http://chain-1338:8545"
      GRAPH_LOG: info
    networks:
      - nxtp-test
  postgres-1338:
    container_name: postgres-1338-test
    image: postgres
    ports:
      - "5433:5432"
    command: ["postgres", "-cshared_preload_libraries=pg_stat_statements"]
    environment:
      POSTGRES_USER: graph-node
      POSTGRES_PASSWORD: let-me-in
      POSTGRES_DB: graph-node
    networks:
      - nxtp-test
  ipfs:
    container_name: ipfs-test
    image: ipfs/go-ipfs:v0.4.23
    ports:
      - "5001:5001"
    networks:
      - nxtp-test

networks:
  nxtp-test:

[leoyvens]

@mattsse @rhlsthrm Thanks for your help in debugging this, could one of you provide the raw response of a successful eth_getBlockByNumber request to fetch the genesis block?