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

How to run with the WebsocketRunner #100

Open
elier opened this issue Jul 31, 2024 · 8 comments
Open

How to run with the WebsocketRunner #100

elier opened this issue Jul 31, 2024 · 8 comments

Comments

@elier
Copy link

elier commented Jul 31, 2024

Based on the run() code, the runner class is selected automatically if not provided:

def run(cli_ctx, account, runner_class, recorder, max_exceptions, path):
    if not runner_class:
        # NOTE: Automatically select runner class
        if cli_ctx.provider.ws_uri:
            runner_class = WebsocketRunner
        elif cli_ctx.provider.http_uri:
            runner_class = PollingRunner
    ...

I couldn't find anywhere how to configure the provider so the ws_uri is used.

if the runner class is provided like:

silverback run "main:app" --network ethereum:mainnet:node --runner silverback.runner:WebsocketRunner

I got:

silverback.exceptions.NoWebsocketAvailableError: Attempted to a use WebsocketRunner without a websocket-compatible provider.

Thanks!

Copy link

linear bot commented Jul 31, 2024

@fubuloubu
Copy link
Member

We migrated that into ProviderAPI because some providers have both and some don't, do that it was easier to use out of the box. But yes, it is currently not possible to do it with ape-node, we can fix that!

cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true or something (maybe let the user write the websocket address in their config?) so that this works correctly

@antazoey
Copy link
Member

antazoey commented Jul 31, 2024

cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true

What about something like this: ApeWorX/ape#2194?

@elier
Copy link
Author

elier commented Jul 31, 2024

What about something like this: ApeWorX/ape#2194?

I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:

node:
  ethereum:
    mainnet:
      uri: ~
      ws_uri: ~
      http_uri: ~

@fubuloubu
Copy link
Member

What about something like this: ApeWorX/ape#2194?

I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:

node:
  ethereum:
    mainnet:
      uri: ~
      ws_uri: ~
      http_uri: ~

what would be the use case of having a separate http_uri from uri?

@fubuloubu
Copy link
Member

cc @antazoey, maybe we can add a config item to node in core called like has_websocket: true

What about something like this: ApeWorX/ape#2194?

Looks great! Yes, it is good we solve this in core because I eventually want to upstream the whole Iterator[...]/AyncIterator[...] methods into something that a ProviderAPI can generate w/ v1.0, simplifying this downstream integration a lot by removing the need to specify what type of runner is being used (also includes upstreaming my SubscriptionManager to web3py or a web3py middleware/extension, but that's a whole different can of worms)

@antazoey
Copy link
Member

I was trying/expecting something like that. I would suggest having the three parameters, uri and http_url could be use indistinctly:

I was considering this as well, and either deprecating uri or have uri check the scheme and work for either (in the case you only need 1)

@elier
Copy link
Author

elier commented Jul 31, 2024

what would be the use case of having a separate http_uri from uri?

I was just thinking in backward compatibility, people con just use uri, or if need to specify both can go as they like :)
Like this:

node:
  ethereum:
    mainnet:
      uri: ~
      ws_uri: ~

or like this:

node:
  ethereum:
    mainnet:
      http_uri: ~
      ws_uri: ~

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

No branches or pull requests

3 participants