feat: API: support typed errors over RPC

[arajasek]

Related Issues

This is work towards, but does not finish #9041

Proposed Changes

• Updates go-jsonrpc.
• Introduces API errors, with only one case right now -- OutOfGas.
• Demo test.

Additional Info

• Needs Support error codes / typed errors go-jsonrpc#36 & tag
• The chief limitation here is that wrapped errors do not get picked up by the RPC code, which relies on reflection. This is a non-trivial issue, although it is not a blocker. I'd like to discuss this with @magik6k, but it doesn't preclude landing this PR.

Checklist

Before you mark the PR ready for review, please make sure that:

• All commits have a clear commit message.
• The PR title is in the form of of <PR type>: <area>: <change being made>
  • example: fix: mempool: Introduce a cache for valid signatures
  • PR type: fix, feat, INTERFACE BREAKING CHANGE, CONSENSUS BREAKING, build, chore, ci, docs,perf, refactor, revert, style, test
  • area: api, chain, state, vm, data transfer, market, mempool, message, block production, multisig, networking, paychan, proving, sealing, wallet, deps
• This PR has tests for new functionality or change in behaviour
• If new user-facing features are introduced, clear usage guidelines and / or documentation updates should be included in https://lotus.filecoin.io or Discussion Tutorials.
• CI is green

[codecov]

Codecov Report

❗ No coverage uploaded for pull request base (release/v1.18.0@37be576). Click here to learn what that means.
The diff coverage is n/a.

❗ Current head 30bd0ed differs from pull request most recent head 3e81c56. Consider uploading reports for the commit 3e81c56 to get more accurate results

Additional details and impacted files

@@                Coverage Diff                 @@
##             release/v1.18.0    #9061   +/-   ##
==================================================
  Coverage                   ?   41.02%           
==================================================
  Files                      ?      708           
  Lines                      ?    78898           
  Branches                   ?        0           
==================================================
  Hits                       ?    32365           
  Misses                     ?    41014           
  Partials                   ?     5519           

[magik6k]

The chief limitation here is that wrapped errors do not get picked up by the RPC code, which relies on reflection.

We could make go-jsonrpc recursively errors.Unwrap the error until it hits a registered error (with some depth limit just in case), then have it return a "wrapped" version of that error:

• What the error code would be in that case is a good question, we can go one of a few routes:
  • Pre-register the 'wrapped' error type, which would marshal into the {errorMsg, subErrCode, subErr} - probably closest how errors are wrapped in Go, but weird in non-Go apps - you can't tell the error type just by looking at the error code in the jsonrpc response
  • Register wrapped error types for each wrapable error type - you can tell the error just by looking at the error code, but now there are 2 error codes per error type.
  • Mix of the above - when registering an error specify if it's wrapable - if it is, always marshal it as wrapped json, if it is not, keep current behavior.

[magik6k]

duplicate import

[arajasek]

fixed

[magik6k]

Tests seem to be broken because of this really robust error check: https://github.com/filecoin-project/lotus/blob/master/itests/kit/blockminer.go#L194 (which we can now make actually robust with this PR)

[magik6k]

Technically those tests should also be moved to api/

[magik6k]

supernit:

Suggested change

	if err != nil && !strings.Contains(err.Error(), "websocket connection closed") && !api.ErrorIsIn(err, []error{&jsonrpc.RPCConnectionError{}}) {
	if err != nil && !strings.Contains(err.Error(), "websocket connection closed") && !api.ErrorIsIn(err, []error{new(jsonrpc.RPCConnectionError)}) {

[dirkmc]

Another use case where this would be helpful:
https://github.com/filecoin-project/boost/blob/a58ea5a92a4237a018f9e7dc700936a5cebb0688/cmd/booster-bitswap/remoteblockstore/remoteblockstore.go#L97-L102

[hunjixin]

@magik6k sorry for these questions after the code merge

Recently venus intended to submit some of venus changes and bug fixes for rpc to the upstream, but when pushing it, it found many conflicts with TypeError

In PR, I think the current implementation of TypeError is a bit complicated.

I'm not sure if users really need the MarshalJson/UnMarshalJson functionality, but I'm looking at lotus/boost usage and it's enough to determine the type of error, and in venus requirements it's enough to determine the type of error.
in addition, I have the impression that adding meta fields may cause errors in the jsonrpc library in rust, which does not allow additional fields. meta is not a in standard jsonrpc protocol.

ErrorCode is a good idea, but maybe more better to define ErrorCode as true error type like below code

type ErrorCode int

func (e ErrorCode) Error() string {
    return fmt.Sprintf("error code %d", e)
}

for rpc server , user fmt.Error to return specific error

if res.MsgRct.ExitCode == exitcode.SysErrOutOfGas {
        return -1, rpc.ErrorCode(exitcode.SysErrOutOfGas)
}

or convert all exitcode to rpc error

if res.MsgRct.ExitCode != exitcode.Ok {
        return -1, xerrors.Errorf("message execution failed: exit %w, reason: %s", rpc.ErrorCode(res.MsgRct.ExitCode), res.Error)
}

for rpc client, use this code to check error type

    require.True(t, xerrors.Is(err, rpc.EOutOfGas))

If write it this way, not need to add the Register function in Rpc, and the Rpc implementation can be simpler without adding the meta field in Respnse.