ethereum_types::uint::U64" failed. Error("invalid type: integer `1`, expected a (both 0x-prefixed or not) hex string or byte array

[diglos]

trafficstars

Describe the bug

We are getting this message every 3-4 seconds on an ARM64 Ethereum node

Steps to reproduce

Start the sync on an ARM64 board

CL consensus data:

Lighthouse v4.2.0-c547a11 BLS library: blst SHA256 hardware acceleration: false Allocator: jemalloc Profile: maxperf

Node logs

Jun 21 07:53:19 ethereumonarm-rock5b-019c33fd4 reth[9369]: 2023-06-21T07:53:19.351300Z ERROR connection{remote_addr=127.0.0.1:37196 conn_id=67363}: jsonrpsee_types::params: [next_inner] Deserialization to "ethereum_types::uint::U64" failed. Error: Error("invalid type: integer `1`, expected a (both 0x-prefixed or not) hex string or byte array containing between (0; 8] bytes", line: 1, column: 1), input JSON: "1,\"latest\",[100]]"
Jun 21 07:53:24 ethereumonarm-rock5b-019c33fd4 reth[9369]: 2023-06-21T07:53:24.283927Z ERROR connection{remote_addr=127.0.0.1:58348 conn_id=67369}: jsonrpsee_types::params: [next_inner] Deserialization to "ethereum_types::uint::U64" failed. Error: Error("invalid type: integer `1`, expected a (both 0x-prefixed or not) hex string or byte array containing between (0; 8] bytes", line: 1, column: 1), input JSON: "1,\"latest\",[100]]"
Jun 21 07:53:26 ethereumonarm-rock5b-019c33fd4 reth[9369]: 2023-06-21T07:53:26.281844Z  INFO reth::node::events: Forkchoice updated head_block_hash=0xfcdd315b97cd909426c7d859f95b741fd009bd0015eb149b728cea259038ebe0 safe_block_hash=0x562b5a955c570a34d537efa2f9844bc444447ac303e4858a6ab2cef37c1f9db2 finalized_block_hash=0xeb02c8aad6d067d0ba94d966622ee903e346df20d2ee3016f309fdd047d1d948 status=Syncing
Jun 21 07:53:27 ethereumonarm-rock5b-019c33fd4 reth[9369]: 2023-06-21T07:53:27.497635Z ERROR connection{remote_addr=127.0.0.1:58432 conn_id=67377}: jsonrpsee_types::params: [next_inner] Deserialization to "ethereum_types::uint::U64" failed. Error: Error("invalid type: integer `1`, expected a (both 0x-prefixed or not) hex string or byte array containing between (0; 8] bytes", line: 1, column: 1), input JSON: "1,\"latest\",[100]]"
Jun 21 07:53:28 ethereumonarm-rock5b-019c33fd4 reth[9369]: 2023-06-21T07:53:28.748795Z ERROR connection{remote_addr=127.0.0.1:58476 conn_id=67380}: jsonrpsee_types::params: [next_inner] Deserialization to "ethereum_types::uint::U64" failed. Error: Error("invalid type: integer `1`, expected a (both 0x-prefixed or not) hex string or byte array containing between (0; 8] bytes", line: 1, column: 1), input JSON: "1,\"latest\",[100]]"

Platform(s)

Linux (ARM)

What version/commit are you on?

alpha1

What database version are you on?

Current database version: 1 Local database version: 1

If you've built Reth from source, provide the full command you used

PKG_CONFIG=/usr/bin/aarch64-linux-gnu-pkg-config PKG_CONFIG_PATH=/usr/lib/aarch64-linux-gnu/pkgconfig/ cargo build --profile maxperf --target aarch64-unknown-linux-gnu

Code of Conduct

• [X] I agree to follow the Code of Conduct

[onbjerg]

Someone/something is calling your RPC w invalid types for parameters, would you happen to know what it might be? (other than CL)

cc @mattsse on this

[diglos]

These are the Reth flags:

node --authrpc.jwtsecret /etc/ethereum/jwtsecret --datadir /home/ethereum/.reth --http --ws

[diglos]

Same error is reported here as well (MAC, which is ARM64 based as well):

#1977

[mattsse]

what's the rpc method this is calling?

you should be able to identify this by setting RUST_LOG=jsonrpsee,reth=info

[mattsse]

I think this is eth_feeHistory

but the endpoints expects a block number QUANTITY according to the spec:

https://ethereum.github.io/execution-apis/api-documentation/

however geth supports hexOrDecimal:

https://github.com/ethereum/go-ethereum/blob/8c288b528d3c9653c84321387e78687ed02134d7/internal/ethapi/api.go#L91-L91

so I think we should also support decimal numbers here

[diglos]

Hi, sorry for the late reply.

Turns out that the node hung up yesterday, we think it was an storage problem. We restarted the sync with another card and the message didn't show up anymore.

I'm reading your response and it makes sense but it seems odd that I couldn't reproduce the issue in the new sync (same LH client and conditions).

[onbjerg]

@diglos Please report that as a separate issue as it is unrelated to the parsing error. Closing this in favor of #3328