Skip to content

Use EthBlockNumberOrHash wherever we need to decode one #12766

@rvagg

Description

@rvagg

In eth.go, and a some other places (including the new TipSetResolver introduced in #12762), we parse these types of eth strings - they can be one of the pre-defined values or a block hash or a block number. The problem is that we have inconsistent handling of them. Sometimes we just take the string and switch it and other times we explicitly json-decode it using EthBlockNumberOrHash.

We should:

  1. Make internal methods that take these strings take a EthBlockNumberOrHash instead
  2. Make our external API methods that currently take a string immediately have to convert it to a EthBlockNumberOrHash before using it
  3. Each method that takes one, should additionally validate that it's within bounds of what it can deal with: sometimes it's not allowed to take certain forms, we should assert that on the EthBlockNumberOrHash that we get back, perhaps add validation methods to EthBlockNumberOrHash itself for common cases. e.g. "earliest" is parsed by some functions and immediately errors, maybe we should handle that?

Needs a little bit of research into the various ETH APIs we support and what go-ethereum (and friends) allows in the various calls.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Status

    📌 Triage

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions