Update fetch middleware to preserve original error data

[sterlu]

Recently the rpc-errors package had been updated to preserve the original RPC error message (MetaMask/rpc-errors#160). However, the fetch middleware in this package has been preventing this as it has not been forwarding the body.error.message string from the response, instead rewriting all errors with the default 'Internal JSON-RPC error.'. This PR addresses that.

The data could also be passed explicitly as rpcErrors.internal({ message: body.error.message, data: body.error.data }) but the approach of passing the whole body.error has the advantage of parseOpts in getJsonRpcError handling the case in which if body.error is not an object but a string.

I wanted to add tests to cover this, but the only way I see this being done is by exporting the parseResponse method. Let me know if this is something you'd like covered.

[mcmire]

Hi @sterlu, thanks for this PR. We will take a look at it soon!

[legobeat]

I wanted to add tests to cover this, but the only way I see this being done is by exporting the parseResponse method. Let me know if this is something you'd like covered.

Rather than unit-testing the internal behavior of this this otherwise unexported function, seems more appropriate to extend fetch.test.ts with tests that instantiate a fetch-middleware using createFetchMiddleware, then testing for that errors result in the expected (serializable?) result? Some similar tests already exist for retryOnEmptyMiddleware (e.g. #154, #254).

but the approach of passing the whole body.error has the advantage of parseOpts in getJsonRpcError handling the case in which if body.error is not an object but a string.

In particular I guess it would benefit from a regression test covering the eventuality of input error objects being cyclical, in order to cover for situations like:

• React-Native crashed when try access err.stack rpc-errors#131
• Background errors not serialized correctly when sent to UI metamask-extension#10090