Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
NetworkController: Add RPC service class (#5163)
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * If your primary goal was to update one package but you found you had to update another one along the way, why did you do so? * If you had to upgrade a dependency, why did you do so? --> This commit adds an RPC service class that will ultimately be used inside of middleware to make JSON-RPC requests to an RPC endpoint. It makes uses of `createServicePolicy`, added in a previous commit, to encapsulate the request code using the retry and circuit breaker policies. As this service class is designed to replace large parts of the fetch and Infura middleware, it customizes the service policy so that the request will be retried only when the network is perceived to be "down". This occurs when: - The `fetch` call throws a "Failed to fetch" error (or something similar to it; see code for the full list of variations) - The `fetch` call throws an ETIMEDOUT or ECONNRESET error - The response status is 503 or 504 - The response body is invalid JSON In contrast, the network is not perceived to be "down" if: - The `fetch` call throws an unexpected error (e.g. if the request options are invalid) - The response status is not 2xx, but is also not 503 or 504 - The response body is an unsuccessful JSON-RPC response - The response body is a successful, but empty, JSON-RPC response ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> Closes #4990. ## Changelog <!-- If you're making any consumer-facing changes, list those changes here as if you were updating a changelog, using the template below as a guide. (CATEGORY is one of BREAKING, ADDED, CHANGED, DEPRECATED, REMOVED, or FIXED. For security-related issues, follow the Security Advisory process.) Please take care to name the exact pieces of the API you've added or changed (e.g. types, interfaces, functions, or methods). If there are any breaking changes, make sure to offer a solution for consumers to follow once they upgrade to the changes. Finally, if you're only making changes to development scripts or tests, you may replace the template below with "None". --> (N/A; internal change only) ## Checklist - [x] I've updated the test suite for new or updated code as appropriate - [x] I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate - [x] I've highlighted breaking changes using the "BREAKING" category above as appropriate - [x] I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes --------- Co-authored-by: cryptodev-2s <[email protected]>
- Loading branch information