Skip to content
This repository was archived by the owner on Oct 16, 2025. It is now read-only.

Update fetch middleware to preserve original error data - #349

Closed
sterlu wants to merge 1 commit into
MetaMask:mainfrom
sterlu:main
Closed

sterlu wants to merge 1 commit into
MetaMask:mainfrom
sterlu:main

Conversation

@sterlu

@sterlu sterlu commented Dec 10, 2024 •

Copy link
Copy Markdown

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.

@sterlu
sterlu requested a review from a team as a code owner December 10, 2024 11:15
@mcmire

mcmire commented Dec 11, 2024

Copy link
Copy Markdown
Contributor

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

@legobeat

legobeat commented Dec 14, 2024 •

Copy link
Copy Markdown
Contributor

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:

@mcmire

mcmire commented Sep 10, 2025

Copy link
Copy Markdown
Contributor

We have moved the core request logic into RpcService in @metamask/network-controller. See here for more: https://github.com/MetaMask/core/blob/b0fd793c6cd3a05145e803e516bee8fc619ccd51/packages/network-controller/src/rpc-service/rpc-service.ts.

Closing this. Please create new issues in the core repo.

@mcmire mcmire closed this Sep 10, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants