ethclient/ethclient.go add_get_block_by_tag_function #30984
Conversation
| @@ -94,6 +94,13 @@ func (ec *Client) BlockByNumber(ctx context.Context, number *big.Int) (*types.Bl | |||
| return ec.getBlock(ctx, "eth_getBlockByNumber", toBlockNumArg(number), true) | |||
| } | |||
|
|
|||
| // BlockByNumber returns a block from the current canonical chain. If tag is nil, the | |||
There was a problem hiding this comment.
You can retrieve the block by using tag with BlockByNumber endpoint.
e.g.
- BlockByNumber(context.Background(), nil) means latest,
- BlockByNumber(context.Background(), big.NewInt(-1)) means pending,
- BlockByNumber(context.Background(), big.NewInt(-2)) means latest,
- BlockByNumber(context.Background(), big.NewInt(-3)) means finalized,
- BlockByNumber(context.Background(), big.NewInt(-4)) means safe,
However, I do see the point for having an endpoint to explicitly request blocks with tag.
While these special negative numbers can be translated by ethclient to tags, they are Geth-related, not publicly defined in the spec. Probably it's better to extend the BlockByNumber endpoint a bit, allowing specify tag explicitly?
cc @fjl
There was a problem hiding this comment.
Thank you for your reply.，Yes, I can know which numbers represent which labels after digging into the code, but it is very inconvenient, so do I need to modify the BlockByNumber method and submit it again?
There was a problem hiding this comment.
I agree the numbers are not very visible right now. After some discussion in team, we don't want to add another method, but would be open to improving documentation. We could also add redefinitions of these constants into package ethclient for convenience.
When querying blocks using special tags, there is no direct method call. It requires delving into the code to find the corresponding number for the special tag and then retrieve the block, which is inconvenient. Therefore, a method was encapsulated to directly query blocks using special tags.