Map VM errors to `FuelError` error codes about fuels-ts

[nedsalk]

I asked @FuelLabs/client the following question:

The graphql API returns an errors array when an error happens on the VM. In practice, are there cases where the VM will return more than one error? If there are none, could we make an assumption that there won't be any in the future? Having this assumption would improve ergonomics for users on our side - a thrown error would always be the error, not a wrapper for multiple errors in some cases and the error in others.

And @Dentosal responded:

My understanding is that the errors array is part of how GraphQL itself works. If you only request one VM operation, then there can only be one VM error.

@LuizAsFight based on this, we can extract the single error from the graphql errors array and throw it. We don't need to handle the multiple errors case because it never happens in reality. The wallet code that you linked to could then maybe be simplified because you wouldn't be working with arrays at all.

[nedsalk]

Speaking of all errors, do we have a unified list of possible errors the VM can throw, or how else should we know when we mapped them all? I suspect this may be something we'll keep mapping as we go.

We have a list of VM error codes in our repo already - it's used in a similar error throwing vein, and the full list can be found here.

[LuizAsFight]

I remember to have seen multiple errors before in the wallet also in other scenarios than a wrong query

[LuizAsFight]

@nedsalk one incorrect query can return multiple errors

query {
  blocks (last: 10, first: "asd") {
    nodes {
      height
      asds
    }
  }
}

response

{
  "data": null,
  "errors": [
    {
      "message": "Invalid value for argument \"first\", expected type \"Int\"",
      "locations": [
        {
          "line": 2,
          "column": 20
        }
      ]
    },
    {
      "message": "Unknown field \"asds\" on type \"Block\".",
      "locations": [
        {
          "line": 5,
          "column": 7
        }
      ]
    }
  ]
}

[nedsalk]

Those errors look like graphql-related errors thrown when writing custom queries. The SDK itself internally should never encounter them because we use Provider.operations, which is type safe because it's generated via graphql-codegen.

Given that custom queries are out of the SDK's scope (currently, depending on if we work on #1570), FuelError shouldn't be concerned with their failure modes; and even if they were in our scope, it's questionable if they should be integrated into FuelError or possibly be a different error class, e.g. GraphqlError, because they're not really domain-specific so that they're included into FuelError but rather they're related to the GraphQL protocol.

It would be great if you could verify if the other scenarios are graphql-related or not, though.

[petertonysmith94]

Adding the cause for unknown errors might be easier?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause

[LuizAsFight]

hey @nedsalk thanks for the heads up

just for context check this file from wallet code

graphql api can return multiple errors, that's why we initially had only e.response?.errors , and after the FuelError was included we needed to add this conditional, forcing the creation of an array containing the error

do you think it makes sense to create 1 FuelError for each occurrence of errors that came from graphql api? that way returning always an array

[arboleya]

I reduced the scope of this issue and moved a portion of it to the below issue, as it will be easier and provide immediate value even before we can map "all" errors.

• #2521

Speaking of all errors, do we have a unified list of possible errors the VM can throw, or how else should we know when we mapped them all? I suspect this may be something we'll keep mapping as we go.

In this sense, I created a first issue here for a recurring error:

• #2522

[LuizAsFight]

as the graphql natively expose errors array I would just safely keep the same pattern instead of hunt situations that multiple errors can happen. but that's my personal opinion as I like my code to be fault-proof. if multiple errors happen, I would be already prepared

if you wanna assume it will be always one error only, sounds good also no big deal, up to you guys

only downside I see is that if we figure this out later may need to refact something

[Torres-ssf]

@nedsalk This seems to be a duplicate of #2208