fix: enforce fallback response integrity & evm user error matching #861
Conversation
|
|
Another fix was also introduced at this PR, since it's error-related. It's the fix to the problem outlined in #862. The current approach is matching server errors, and user error is anything with -32k error and NOT a server error. Since server errors are fewer, it is easier to handle and node runners won't be penalized by false positives on EVM unknown user error messages. |
| if (isRelayError(stringifiedResponse) && !isUserError(stringifiedResponse)) { | ||
| throw new Error(`Response is not valid: ${stringifiedResponse}`) | ||
| } |
There was a problem hiding this comment.
makes sure that the response obtained from altruist is a good one
|
|
||
| // 3 is execution error | ||
| // -32000 itself can be thrown for what are server errors | ||
| // all other -32000 are user errors | ||
| return userError || code === 3 || code < -32000 | ||
| return (!serverError && code === -32000) || code === 3 || code < -32000 |
There was a problem hiding this comment.
anything thats not a server error & has error code -32k is assumed to be an user error, not node error.
crisog
changed the title
The fallback responses are the ones coming from our backup system. They come into play when the node selected from the network can't do it's job, and doesn't return any response. In our mission to be as fast as we can, we use our internal system to serve that request (doesn't generate revenue).
These responses were only enforced to a certain format, but the truth is that there are other several server errors from blockchain's node clients that indicate that the call wasn't effective. This PR adds some additional text enforcement to abstract these errors from users and let it fail without any specific blockchain's node message that could add confusion to end user.
Example error: