Open rvagg opened 3 days ago
Thanks to @eshon to alerting me to https://github.com/graphprotocol/graph-node/issues/4729#issuecomment-1650257347
It turns out that the ErrNullRound
string is a hard-wired expectation in TheGraph: https://github.com/graphprotocol/graph-node/pull/5294/files#diff-b31a71a95f48aa7d0f11b5ea3501befc2560d749d73872e9eebe8003de85d921R1090-R1099
So we just need to make sure we don't mess with that, and it also might be worth putting a note in there for that error // don't change this error string, it's used by downstream tools to detect a null round
.
I'm only realising that this comes from the fix in https://github.com/filecoin-project/lotus/issues/10909, and before that we returned an error and I'm now advocating that we return an error. Sorry @virajbhartiya and @aarshkshah1992 I know you've been all over that issue and its fix @ https://github.com/filecoin-project/lotus/pull/12529 but I think we need to revisit that because null
isn't going to work as per the above reasons. I think we should just error with a very clear reason.
I think reverting that change is the right answer here.
@virajbhartiya -> Let's just ensure that we return ErrNullRound
like we used to for that API and also make this change in all the ETH RPC APIs listed on this issue.
While it is unfortunate -> looks like this Filecoin specific behaviour wrt null rounds(ETH does not have null rounds) has now been OSSified and ETH tooling has come to depend on it.
eth_getBlockByNumber
uniquely handles null rounds by returning anil
response (null
via RPC), whereas all the othereth_
APIs that take a block number will return an error.go-ethereum's behaviour seems to be that
null
indicates that the number isn't available, or at least can't be found in the number<>block mapping, which sounds like it'd be the right thing for us to do for null rounds, but users take this to mean that the block isn't yet available but will become at some point if they keep on polling for it because they just got ahead of the chain.From @ilyalukyanov:
We have special handling for null rounds in this API that returns
nil
: https://github.com/filecoin-project/lotus/blob/02a8b972db82eee0ff109366f57122caf7790128/node/impl/full/eth.go#L346-L354We should return a consistent error for all of these cases, currently we don't. All cases of
getTipsetByBlockNumber
:EthGetBlockByNumber
: returnnil
EthFeeHistory
: return error:bad block parameter X: requested epoch was a null round
FilecoinAddressToEthAddress
:failed to get tipset for block X: requested epoch was a null round
EthTraceBlock
:failed to get tipset: requested epoch was a null round
EthTraceReplayBlockTransactions
:failed to get tipset: requested epoch was a null round
We should make these consistent.
ErrNullRound
dynamic and let it include the requested block number/string:"block number 0x1234 was a null round"
errors.Is
forErrNullRound
and return theerr
directly (orerrors.As
and return the instance?)ErrNullRound
return a nested error description, but let's make it consistent eh?