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

Checking if a provider supports subscriptions by checking for "on" property often breaks #3432

Closed
dmihal opened this issue Mar 26, 2020 · 2 comments · Fixed by #3517
Closed
Labels
1.x 1.0 related issues Bug Addressing a bug

Comments

@dmihal
Copy link

dmihal commented Mar 26, 2020

When a transaction is sent, web3 chooses to either poll for a receipt, or subscribe to new blocks. However, it makes this decision by checking if on is a property of the provider:

https://github.com/ethereum/web3.js/blob/af6472976c23cb61c05e925eebe5734d141384f4/packages/web3-core-method/src/index.js#L515-L521

This means if a project is using a provider that includes on, such as web3-provider-engine, it will incorrectly try to subscribe. This can cause errors when sending a transaction:

image

The workaround I've used is to remove on from a provider, however I imagine this may break some providers or apps.

const provider = new ProviderEngine();
provider.on = null;
const web3 = new Web3(provider)

I'm not sure what the correct way is to determine whether a provider supports subscriptions is, maybe this needs to be addressed in the provider spec/API?

@cgewecke
Copy link
Collaborator

@dmihal Thanks for reporting. Out of curiosity, which provider-engine version are you using?

@dmihal
Copy link
Author

dmihal commented Mar 26, 2020

Thanks @cgewecke, I'm using web3-provider-engine@15.0.6

I also had the same problem while building burner-wallet/burner-connect-provider. I wanted to implement the EventEmitter interface, but had to remove on as well:

image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1.x 1.0 related issues Bug Addressing a bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants