Skip to content
This repository has been archived by the owner on Dec 27, 2022. It is now read-only.

Implement custom RPC Provider with Fallback #640

Draft
wants to merge 13 commits into
base: main
Choose a base branch
from
Draft

Conversation

jakekidd
Copy link
Contributor

The Problem

The Solution

Copy link
Contributor

@rhlsthrm rhlsthrm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to do the StaticJsonRpcProvider instead of JsonRpcProvider.

modules/types/src/network.ts Outdated Show resolved Hide resolved
} else {
const providers = (this._provider as FallbackProvider).providerConfigs.map(p => p.provider as JsonRpcProvider);
var errors: Error[] = [];
return Promise.race<any>(
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that here is where we are executing the Promise.race. Essentially, in any other method call in this class, we literally just call the underlying provider. Fallback provider does this sort of 'race-like' operation we see here internally, under the hood.

However, there is no FallbackProvider.send method, so I've taken the liberty of implementing this myself. Assuming we had multiple provider URLs passed into constructor (and therefore we're using FallbackProvider), we're basically executing the RPC send call on every child provider (AS JsonRpcProvider) belonging to our FallbackProvider, and using a Promise.race to return the fastest one.

A delay for timeout of 10s rejects the Promise. Additionally, if all send calls error out, we reject the Promise with a list of errors.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Going to add the above in descriptive comments here.

@LayneHaber
Copy link
Contributor

Update June 7

Work on this is deprioritized temporarily (will likely resume next week).

Currently blocked by an issue with the ethprovider image. Specifically, when running integration tests the contracts fail to deploy because the image does not recognize the symlinked types package.

When creating the ethprovider image, there are dependencies installed that are listed here which the image has access too. The symlinked packages are generally only accessible by the vector_builder image, which is the image used by the server-node package in the duet and trio stacks.

To move forward, we have to give the images used in the chains stack access to the symlinked packages. This means replacing the ethprovider image with the builder image within the start-chains script.

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