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

Async name_to_address middleware #1990

Closed
kclowes opened this issue May 10, 2021 · 2 comments · Fixed by #3012
Closed

Async name_to_address middleware #1990

kclowes opened this issue May 10, 2021 · 2 comments · Fixed by #3012

Comments

@kclowes
Copy link
Collaborator

kclowes commented May 10, 2021

What was wrong?

The name to address middleware relies on calls to an RPC server. In order to have a full async pathway, web3py needs an async version of the middleware that will use an async w3 instance.

How can it be fixed?

Add an async_name_to_address_middleware that can be used in the async pathway. This issue builds on #1986, and will depend on #1987.

@kclowes kclowes self-assigned this Jun 22, 2021
@kclowes kclowes mentioned this issue Jun 22, 2021
2 tasks
@kclowes kclowes mentioned this issue Jul 22, 2021
1 task
@dbfreem
Copy link
Contributor

dbfreem commented Feb 4, 2022

So I started working on this the other day since I felt like it was one of the shortcomings of the Async Provider currently. There were a couple of module level methods that needed to be asynced in contracts to call the eth.call async method. Also, I was thinking of creating an AsyncContractFuntion. This wouldn't be a full implementation of ContractFunction in Async but just enough to get bye to make the ENS contract call. Also, was thinking of doing it in pieces. One PR for AsyncContractFunction, one for ENS methods needed for the middleware, and one PR for the middleware itself. This might make it more manageable and easier to review the PRs.

@kclowes or anyone else have any thoughts on this approach.

@kclowes
Copy link
Collaborator Author

kclowes commented Feb 4, 2022

@dbfreem that approach sounds like what I would do as well, thanks for taking it on! Smaller PRs are preferred since they tend to be so much easier to review, and breaking it up like you suggest makes sense to me.

/cc @pacrob since you've been working on an async Contract

@dbfreem dbfreem mentioned this issue Mar 2, 2022
3 tasks
@kclowes kclowes removed their assignment Jul 18, 2022
@fselmo fselmo mentioned this issue Dec 13, 2022
2 tasks
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 a pull request may close this issue.

2 participants