Ethers.js: Add willPoll and didPoll events to provider.

[marcelomorgado]

I'm currently test events that way:

const sentTx = await contract.setValue("hello world");

await new Promise(function(resolve, reject) {
  contract.on("ValueChanged", (...args) => {
    const event = args.pop();
    // do something
    resolve();
  });
});

I'm trying to rewrite this but sending transaction after event subscribing:

contract.on("ValueChanged", listener);
const sentTx = await contract.setValue(newValue);

await mineBlocks(provider, 1); 
await wait(provider.pollingInterval * 2);

But that only works if I raise how many blocks to mine and/or the waiting time.
I'm trying to simulate a blockTime > pollingInterval (as on real blockchain).
Am I doing something wrong here?

Related question: Is there a way that I can wait for polling? I guess that could be occurring because doPoll routine is undetermined (some promise.then() calls).

Note: ganache-cli with no blockTime

Thanks!

[ricmoo]

I could add some additional events, such as "willPoll" and "didPoll"?

Here is a quick example of how I test events: https://docs.ethers.io/ethers.js/html/cookbook-testing.html

I do not use Ganache, but would it work if you switched the order? Do the wait, then mine the blocks?

[marcelomorgado]

Hi @ricmoo, thanks to respond me,

A. The "didPoll" event will be great! Is it possible to fire that after doPoll routine ends completely (after calling all event listeners subscribed)?

B. Thanks, I've used that on my tryouts.

C. I've tried it either but not work, the way that I've posted seems better because first the new block is mined and then will be waiting for the next poll.

Thanks!

[pcowgill]

@ricmoo Should we rename this issue to something like Add additional events like willPoll and didPoll? Thanks!

[ricmoo]

Ah good idea. I’ll do that now.

I’ll probably add it to v5, which will have a beta out soon. :)

[ricmoo]

(it’s a bit more involved than I planned, so that we can ensure the event is triggered after all handled listeners, which is why I want to move it to v5, where we have more room to possibly break full backwards compatibility and the even system is simpler)

[ricmoo]

This has been added to the v5 branch. The didPoll event will not trigger until all promises it generates resolve, so that means the order of didPoll may arrive out-of-order.

For example, if there are a bunch of filter events that are being listened to, and a willPoll triggers, each filter will require a getLogs. If while the getLogs is running, all these filter events are removed, and another willPoll triggers, the didPoll for the second willPoll does not have any blocking promises, so it may occur before the first. This should not matter for most cases, but it is something to keep in mind. Yay asynchronous. :)

Anyways, let me know I you have any problems with it.

Thanks! :)