FuelLabs
Map VM errors to `FuelError` error codes
- Create
ErrorCodeentry for every VM error - Every
ErrorCodeentry 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 targetand:- Verify that a
FuelErrorwith thenot-enough-coinscode is thrown - Verify that
FuelError.rawErrorcorresponds to the serialized VM error - this would be done with afetchspy
- Verify that a
- e.g. bring the VM to throw
cc @LuizAsFight
[!NOTE] Should be done after:
- https://github.com/FuelLabs/fuels-ts/issues/2521
Adding the cause for unknown errors might be easier?
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error/cause
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
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.
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
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.
@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
}
]
}
]
}
I remember to have seen multiple errors before in the wallet also in other scenarios than a wrong query
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.
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
@nedsalk This seems to be a duplicate of https://github.com/FuelLabs/fuels-ts/issues/2208
