Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jb/l1 client #2434

Merged
merged 5 commits into from
Jan 7, 2025
Merged

Jb/l1 client #2434

merged 5 commits into from
Jan 7, 2025

Conversation

jbearer
Copy link
Member

@jbearer jbearer commented Jan 3, 2025

Closes #2360
Closes #1238

This PR:

  • Uses HTTP for non-subscription RPC requests, even if a WebSockets provider is also given
  • Tracks RPC request failures and fails over to another provider if possible when the current provider is failing too often
  • Handles rate limit (429) errors from the provider

Copy link
Contributor

@rob-maron rob-maron left a comment

Choose a reason for hiding this comment

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

Looks good, one minor q

types/src/v0/v0_1/l1.rs Show resolved Hide resolved
types/Cargo.toml Outdated Show resolved Hide resolved
There are many reasons to avoid using WebSockets for regular RPC
requests. Some of these reasons are enumerated
[here](https://docs.alchemy.com/reference/best-practices-for-using-websockets-in-web3#reasons-to-use-https-instead-of-websockets-for-json-rpc-node-requests)

This change reorganizes the L1 client so that instead of having an
HTTP provider _or_ a WebSockets provider, we have both. The HTTP
provider is used for regular RPC requests and the WebSockets provider
is used for subscriptions only. Each type of provider is now doing
what it does best, and this is evidenced in the code changes:
* we delete the complicated reconnect handling for WebSockets on failed
  RPC requests. HTTP was never subject to this complexity because each
  request is already a separate connection
* we no longer need stub methods for subscriptions for HTTP provider because
  we are no longer trying to present a unified interface that can be implemented
  by HTTP or WebSockets
* the timeout logic for subscriptions, while still in the code, is less important
  because it never affected WebSockets in the first place

We have kept the WebSockets provider as optional, since not all providers support
WebSockets. In case it is not provided, we will fall back to the old HTTP polling-based
implementation of subscriptions, which is why we need to keep the timeout logic in there.

See #2360
Allow the L1 client to be configured with multiple RPC provider URLs.
Fail over to the next provider in the list if
* two requests fail in a given time period
* N requests fail in a row

Handle rate limit errors specially by preventing requests to the
provider until the rate limit period expires.

Closes #2360
@jbearer jbearer merged commit fa44122 into main Jan 7, 2025
24 checks passed
@jbearer jbearer deleted the jb/l1-client branch January 7, 2025 21:17
@jbearer jbearer mentioned this pull request Jan 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

L1 client improvements Allow to setup multiple RPCs in the .env for fallback
2 participants