Unreliable event filtering

The cookbook provides a strategy for testing events, using contract.on. However, this only seems to be reliable if run in a single test suite.

A separate part of the cookbook presents a strategy for returning a value from a state-changing function. This strategy can also be used to test events.

Going by the cookbook, we at Magmo used the first strategy. However, it forced us to run our jest test suites in serial with the --runInBand option. This is both time consuming, and worrying, since we cannot trust the behaviour of contract.on based on this issue.

Here is a repository reproducing the issue. On the first commit, yarn test will not work, but yarn testInBand will reliably work. On the second commit, yarn test will reliably work.

[ricmoo]

We are still investigating, and plugging console.log statements all over the place, but it seems certain there is something wrong with how the initial getBlockNumber() is being used for the very first filter.

Thanks for your patience. 😃

[ricmoo]

Huge thanks to @yuetloo for all her efforts in debugging this.

A fix has been added, and the tests are running, after they pass (usually about an hour) I will publish to NPM and update this ticket.

This has identified a few other quirks with events, which I’m addressing right now with the re-write of the v5 events.

Thanks!