Node fails to decode variable length block nonce from RPC

[evmgolf]

Do you want to request a feature or report a bug? Bug

What is the current behavior? If the RPC returns a variable length nonce for calls such as eth_getBlockByNumber, the node is not able to parse the response and refuses to accept the RPC.

If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Tested with foundry-anvil 0.1.0 and graph-node commit 02623ba2e4d20b5bd6aabdeae11947767ec84584

1. Run anvil --host 0.0.0.0 with the host binding to ensure it can be reached from Docker
2. Run docker-compose up in graph-node/docker and observe: eth_getBlockByNumber(0,` false) RPC call failed (attempt #12) 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 applied a simple proxy to replace variable length nonce's with fixed length, and the error disappears.

What is the expected behavior? According to the official RPC spec nonce is of type bytes, which can be any length. So the graph-node parser should observe this standard instead of expecting a fixed length nonce.

[evmgolf]

On further investigation, the Ethereum Yellow Paper says a Block has nonce: A 64-bit value ... Is it the responsibility of the graph-node to accept non padded <16char hex values, or should all RPCs pad their nonce values to strictly comply with the Yellow Paper?

[azf20]

hi @evmgolf! thanks - I think if the anvil RPC could pad to comply that might be preferable here, though as you say the spec leaves room for interpretation

[github-actions[bot]]

Looks like this issue has been open for 6 months with no activity. Is it still relevant? If not, please remember to close it.