Closed amncjf closed 1 month ago
Can you elaborate on the benefits of the recommended response?
I'm afraid that returning info about the previous block wouldn't be clear enough for the users so it's better to return explicit error.
There will be no such errors in Ethereum. Most software and libraries are developed according to this setting, such as ethers, web3js, graph_node..., and they are also used to this setting when calling ethereum rpc. If you follow the current practice of filecoin, these The software needs to be modified. Returning an exception just obviously gives us the information that filecoin is empty. Most of the time we don’t need this information. If we return { ...prevBlock, parentHash: prevBlock.hash, blockNumber: prevBlock. blockNumber+1, } We can also judge whether a block is a filecoin empty block (hash == parentHash) Thanks!
@virajbhartiya
Want to take this one ? Note that this API now supports returning "null" responses if no such block exists and so we should change the signature of the RPC methods accordingly and simply return a "null" value if the requested epoch is a null round.
See https://docs.infura.io/api/networks/ethereum/json-rpc-methods/eth_getblockbynumber and the implementation in go-ethereum
.
@aarshkshah1992 Yes I would like to work on this!
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
Describe the Bug
I in https://api.hyperspace.node.glif.io/rpc/v1 call getBlock (294023) interface, return an Error: Error: requested epoch was a null round, Recommended return: { ...prevBlock, parentHash: prevBlock.hash, blockNumber: prevBlock.blockNumber+1, }
Logging Information