Closed ArseniiPetrovich closed 3 weeks ago
/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.
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.
@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"
.
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: https://github.com/filecoin-project/lotus/pull/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).
Checklist
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.Lotus component
Lotus Version
Repro Steps
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{"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