It seems that the latest eth_getBlockReceipts doesn't properly work when querying for block hash

[ArseniiPetrovich]

Checklist

• This is not a security-related bug/issue. If it is, please follow please follow the security policy.
• I have searched on the issue tracker and the lotus forum, and there is no existing related issue or discussion.
• I am running the Latest release, the most recent RC(release canadiate) for the upcoming release or the dev branch(master), or have an issue updating to any of these.
• I did not make any code changes to lotus.

Lotus component

• lotus daemon - chain sync
• lotus fvm/fevm - Lotus FVM and FEVM interactions
• lotus miner/worker - sealing
• lotus miner - proving(WindowPoSt/WinningPoSt)
• lotus JSON-RPC API
• lotus message management (mpool)
• Other

Lotus Version

Daemon:  1.29.2-rc1+mainnet+git.4004ca6+api1.5.0
Local: lotus version 1.29.2-rc1+mainnet+git.4004ca6

Repro Steps

1. Run curl --location --request POST 'http://localhost:1234/rpc/v1' --header 'Content-Type: application/json' --data-raw '{ "jsonrpc":"2.0","method":"eth_getBlockReceipts","params":["0xdc7c0197634c7c03adf6c3b44559009bc81278269183e97be4974b65c6425ccf"],"id":1}' against Lotus node
2. See error {"error":{"code":-32700,"message":"unmarshaling params for 'eth_getBlockReceipts' (param: *ethtypes.EthBlockNumberOrHash): invalid block param"},"id":1,"jsonrpc":"2.0"}

Describe the Bug

I think API is not properly handling the referring via the block hash or something

Logging Information

can't provide logs

[rvagg]

/cc @virajbhartiya

Hopefully this is fairly straightforward, it just looks like an input processing bug.

Thanks for reporting this while we're still in RC @ArseniiPetrovich! We'll get it sorted ASAP.

[virajbhartiya]

I feel the function expects the input to be something like

curl --location --request POST 'http://localhost:1234/rpc/v1' \
--header 'Content-Type: application/json' \
--data-raw '{
    "jsonrpc":"2.0",
    "method":"eth_getBlockReceipts",
    "params":[{"blockHash": "0xdc7c0197634c7c03adf6c3b44559009bc81278269183e97be4974b65c6425ccf"}],
    "id":1
}'

Instead of passing the block hash directly, it needs to be passed as a key/value pair.

[rvagg]

@ArseniiPetrovich I think the expected ETH behaviour for this is to either take a block number (epoch) encoded as hex, or one of latest, finalized, pending, safe. I don't believe it's supposed to support the long tipset key encoded hash. However, there is one resource out of the many I've looked at that does suggest a hash is appropriate: https://docs.alchemy.com/reference/eth-getblockreceipts.

The usage that @virajbhartiya is correct as per the implementation we have, and is similar to eth_call, eth_getTransactionCount, eth_getCode, eth_getStorageAt and eth_getBalance, which are all standard Ethereum calls. The non-standard ones, implemented by alternative clients and RPC providers, like eth_getBlockReceipts tend to follow the same patterns. But that one doc at Alchemy suggests that at least one RPC provider may take a full block hash, which I guess would be the equivalent of a tipsetkey cid for us, but I don't believe we've got anything that currently works that way. Our translation of "block" is to tipset, we don't resolve anything to a specific block within a tipset and treat all messages in the tipset as transactions of that block.

Is this API usage coming out of Graph software, or are you testing this manually yourself? The working equivalent of your call is either {"blockHash": "0xdc7c0197634c7c03adf6c3b44559009bc81278269183e97be4974b65c6425ccf"} as per @virajbhartiya's code above, or with the block number: "0x41d32b".

[rvagg]

Oh, here's the spec that outlines the format we accept for specifying the block for these calls: https://eips.ethereum.org/EIPS/eip-1898

Found via the original PR that introduced this functionality: #10815

(I was trying to figure out where the {"blockHash":... functionality that we support came from cause Googling doesn't help much on the various RPC docs out there).