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

bug: Fallback public client with WS transport doesn't use eth_subscribe #776

Closed
1 task done
arjun-io opened this issue Jun 24, 2023 · 5 comments
Closed
1 task done

Comments

@arjun-io
Copy link
Contributor

Is there an existing issue for this?

  • I have searched the existing issues

Package Version

1.1.6

Current Behavior

When using a fallback provider with a websocket transport underneath, the provider does not use subscriptions and instead reverts to polling over the websocket connection.

Expected Behavior

If a fallback provider is used, and the attempted transport being used is websocket, use eth_subscribe

Steps To Reproduce

See minimal repo -> Network Inspector -> Websocket connection

image

Link to Minimal Reproducible Example (StackBlitz, CodeSandbox, GitHub repo etc.)

https://stackblitz.com/edit/viem-getting-started-ynbq9a?file=index.ts

Anything else?

No response

@arjun-io
Copy link
Contributor Author

arjun-io commented Jun 24, 2023

Since the eth_subscribe based functions only check for the top level transport (https://github.com/wagmi-dev/viem/blob/main/src/actions/public/watchBlocks.ts#L100) and the fallback transport doesn't have any ability to surface the type of transport it is attempting, it might take a bit of a refactor to handle this... Potentially the fix here is to give some level of introspection to the fallback transports currently used transport and use that in the enablePolling check?

Edit: An alternative easy fix might be to change the type here: https://github.com/wagmi-dev/viem/blob/main/src/clients/transports/fallback.ts#L146 to something like

type: transports.every(t => t.type === 'webSocket') ? 'webSocket' : 'fallback'

and also exposing the subscribe function of the transport

@deHB6
Copy link

deHB6 commented Jul 4, 2023

Experiencing this as well, when I add webSocketPublicClient, watch: true no longer works on my useContractReads

@wk0
Copy link
Contributor

wk0 commented Nov 13, 2023

is this still a problem?

@arjun-io
Copy link
Contributor Author

is this still a problem?

It appears show, I just retried the stackblitz with an updated version of Viem.

@jxom jxom closed this as completed in 0b0df52 Apr 21, 2024
Copy link
Contributor

This issue has been locked since it has been closed for more than 14 days.

If you found a concrete bug or regression related to it, please open a new bug report with a reproduction against the latest Viem version. If you have any questions or comments you can create a new discussion thread.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators May 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants