Map VM errors to `FuelError` error codes

[nedsalk]

• Create ErrorCode entry for every VM error
• Every ErrorCode entry that maps to a VM error must have a test associated with it:
  • e.g. bring the VM to throw not enough coins to fit the target and:
    • Verify that a FuelError with the not-enough-coins code is thrown
    • Verify that FuelError.rawError corresponds to the serialized VM error - this would be done with a fetch spy

cc @LuizAsFight

[!NOTE] Should be done after:

• https://github.com/FuelLabs/fuels-ts/issues/2521

[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

[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.

[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.

• https://github.com/FuelLabs/fuels-ts/issues/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:

• https://github.com/FuelLabs/fuels-ts/issues/2522

[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]

@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
        }
      ]
    }
  ]
}

[LuizAsFight]

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

[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.

[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