-
Notifications
You must be signed in to change notification settings - Fork 1.8k
WebsocketProviderV2 updates + formatting middleware bugfix #3116
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
WebsocketProviderV2 updates + formatting middleware bugfix #3116
Conversation
- Add a proper ``__anext()__`` setup for listening to an open websocket connection. This is the more appropriate pattern without the necessity for a while loop. This also more directly mirrors the ``websockets`` library example and design pattern. - Update documentation example to reflect the above changes.
- Change async_generator -> async_ctx_manager (Context Manager) as this is a more appropriate name for the pattern. - Create a PersistentConnectionProviderTest class and have both the context manager and iterator test suite run these tests. - Add static eth_subscribe tests to keep our formatters and middlewares in check. + additional improvements to typing; pass linting
15bac16 to
58e5576
Compare
- Simplify the json encoding for the static eth_subscription tests - Connect to websocket when entering the AsyncIterator pattern for WebsocketsProviderV2 if it isn't already connected
- We create transient caches on a per-provider basis. This wouldn't be shared among threads to begin with. The async_lock() utility was designed because the request session cache exists outside of any class and thus is shared across many instances of classes that utilize it. Change the async lock around transient caches to be a standard use of the ``asyncio.Lock()``. - Move the lock into the RequestProcessor class since that's where the caches live.
7437a3f to
6a8d428
Compare
reedsa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remaining nits, looking good otherwise!
f67ac1b to
b2ec70f
Compare
4466efa to
9d275c4
Compare
9d275c4 to
ed1947e
Compare
ed1947e to
3ab234e
Compare
3ab234e to
bbe0456
Compare
- We weren't caching every time we held a response. This lead to missing some messages entirely from the provider. This will need some better testing to ensure this logic never breaks. - When popping a raw response, actually return it. I'll add a test for this in a separate commit as well.
- Test that we cache any undesired messages until we find the one we want and return it. - Test that we return the cached response if in cache without ever calling recv()
- Add tests for ``syncing`` eth_subscribe requests - Tweak formatters keyset match to 75% match. Across all eth_subscribe requests, the keys are not close to being similar so we can afford a more relaxed check here.
bbe0456 to
677d7f2
Compare
677d7f2 to
af9adc8
Compare
- Use the call timeout for the provider to set up a reasonable escape time for the while look that tries to match the response `id` with the request `id`. All providers should technically return matching ids in the response but we've run into issues with this in the past and this prevents an infinite loop, handling it somewhat gracefully. - Make sure that the ``WebsocketProviderV2`` sets a default timeout.
af9adc8 to
e6995a8
Compare
pacrob
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm!
| if self.call_timeout and self.call_timeout <= 20 | ||
| else 20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should use the DEFAULT_PERSISTENT_CONNECTION_TIMEOUT constant here.
| if self.call_timeout and self.call_timeout <= 20 | |
| else 20 | |
| if self.call_timeout and self.call_timeout <= DEFAULT_PERSISTENT_CONNECTION_TIMEOUT | |
| else DEFAULT_PERSISTENT_CONNECTION_TIMEOUT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this an entirely different bit of logic though? What if we agree to change the default timeout? I think that was the point of hard-coding this here.
Let's say I don't want each call to the provider to take more than, say, 5 seconds. I wonder if I'm subscribed to a lot of subscriptions, if the response to my call won't be bogged down by the latency behind so many subscriptions where it may actually take longer than a call timeout to receive it.
Thoughts there?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's fine then, I have no concerns with using the hardcoded value as is. Definitely would be overkill to create yet another constant just for this logic.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah in the same way I think using self.call_timeout feels a bit disingenuous to use here too but at least the user can tweak that to make sense if desired. Definitely open to re-thinking this a bit more before ripping off the beta tag.
reedsa
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚀 ![]()
What was wrong?
WebsocketProviderV2needed tests for subscriptions. While we revamp the test suite and try to get some actual integration tests foreth_subscribe, introduce some static tests to make sure our formatters and middleware work appropriately for subscriptions.idto the requestidfor a request. Also improves on the logic around matching the ids, simplifying it.idnever comes (see above bullet point for test case).Todo:
Cute Animal Picture