Use Better Error Codes For GraphQL Client Errors

[Torres-ssf]

We need to improve the error codes used when a GraphQL query/mutation/subscription throws an error from the client. This should be done on:

1 - FuelGraphqlSubscriber

2 - Provider.createOperations

This involves analyzing the errors array returned from the graphQL response. An error entry looks similar to this:

  {
    message: 'not enough coins to fit the target',
    locations: [ { line: 2, column: 3 } ],
    path: [ 'coinsToSpend' ]
  }

In this case, we can identify that the error was caused by the query coinsToSpend, and the error message is not enough coins to fit the target.

When implementing this error handling, is essential to identify what was the path ( query/mutation/subscription ) and use a proper FuelError code

Related to this comment

[arboleya]

The scope of this issue seems a bit open.

What do you think one should do here exactly?

• Go through all the errors and format them?
• Which are the errors? How should they be formatted?

This sort of thing.

[Torres-ssf]

@arboleya I believe we just need to use more specific error codes.

For instance, if we validate that the used path was the mutation submit or even the subscription submitAndAwait,

{
  message: 'error message here',
  locations: [ { line: 2, column: 3 } ],
  path: [ 'submit' ] // or ['submitAndAwait']
}

Then we can use a more appropriate error code, like: TRANSACTION_FAILED, because we know for sure that these 2 are used only when submitting a transaction.

throw new FuelError(
  FuelError.CODES.TRANSACTION_FAILED,
  graphQlResponse.errors[0].err.message)
);

We do not need to treat messages, since we can use the same ones thrown by the client.

Perhaps we should start using better error codes only for transaction submission failure. If we validate that the extracted path is not related to transaction submission, we can use the generic error code INVALID_REQUEST

[petertonysmith94]

Is this related to or the same as?

• Map VM errors to FuelError error codes #2467

[petertonysmith94]

Going to unassign myself from this for now.

[Torres-ssf]

Closing this in favor of #2467