Ganache-cli: Events not functioning as expected

[aakilfernandes]

Expected Behavior

contractInstance.MyEvent({}, {fromBlock:0, toBlock:'latest'}).get(function(err, results){}) does not return results correctly

Current Behavior

Always returns empty results array

Steps to Reproduce (for bugs)

1. Checkout out my event-test branch [email protected]:SafeMarket/testrpc.git#event-test
2. Run npm test
   

   Context

This is the relevant test case https://github.com/SafeMarket/testrpc/blob/event-test/test/requests.js#L531-L537

[genecyber]

duplicate of #87 & #50 & #8 & #74

I was able to run into this issue quickly. I have an API call wrapped around web3.js that returns all events from genesis to now against some contract. I get zero results back.

I haven't tried watching events, I might workaround this issue by watching all events and storing them in a temporary store + modifying my API to pull events from the alternate datastore...

[SilentCicero]

@tcoulter ^^^ this needs to be addressed -- I'm going insane here.

[tcoulter]

So apologies for the late response on this. I've written tests for events recently and they seem to work fine on the latest TestRPC. Please check my comment here: https://github.com/ethereumjs/testrpc/issues/118#issuecomment-232201066

It's likely that you're setting up your listener _after_ the TestRPC mines a block. Thus, the TestRPC is exposing a race condition in your application you didn't know you had. Always set up your listener _before_ making the transaction that fires the event.

Please reopen if you're still seeing this issue.

[genecyber]

Shouldn't get history from Genesis to now return all events no matter where
the lister gets called?

On Thursday, July 21, 2016, Tim Coulter [email protected] wrote:

So apologies for the late response on this. I've written tests for events
recently and they seem to work fine on the latest TestRPC. Please check my
comment here: #118 (comment)
https://github.com/ethereumjs/testrpc/issues/118#issuecomment-232201066

It's likely that you're setting up your listener _after_ the TestRPC
mines a block. Thus, the TestRPC is exposing a race condition in your
application you didn't know you had. Always set up your listener _before_
making the transaction that fires the event.

Please reopen if you're still seeing this issue.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ethereumjs/testrpc/issues/113#issuecomment-234343347,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAK8oqc1Wd9C_ZIddipCHd83koL5AZCkks5qX7uxgaJpZM4JAk23
.

[tcoulter]

The details of .get(), which is provided by web3, go like this:

When you create an event object, like the following in the test, it issues a eth_newFilter call to the client:

var event = instance.NumberEvent([{number: expected_value}]);

Note that the eth_newFilter call is created with no parameters passed -- this is something web3 does, and not the TestRPC. According to the documentation, eth_newFilter passed with no options produces a fromBlock of "latest" -- which means it references this filter off the current block:

https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_newfilter

When you call .get(), Web3 produces an eth_getFilterLogs request which bases its data off of the from block used when the filter was created. Thus, this gives you all the logs from that block onward.

https://github.com/ethereum/wiki/wiki/JSON-RPC#eth_getfilterlogs

Now, if you're ordering your operations incorrectly, you're going to create the event after the transaction is mined (on the TestRPC, at least). Which means that the from block is going to be the "latest" block after the transaction you submitted triggered the event. Which means that, according to the filter, no event has been fired.

As far as I can tell, this is how it's supposed to work from the spec. Nothing that I've seen so far ensures get() produces log values from the genesis block unless you explicitly create your event to be based from block 0.

[tcoulter]

Hmm, I didn't see in this issue specifically @aakilfernandes is creating the event from the genesis block. My misunderstanding.

Let me investigate.

[tcoulter]

Confirmed issue in the web3-provider-engine, which is what handles filters for the TestRPC -- it completely ignores the fromBlock option. Fixing it now and will have a PR up today.

[tcoulter]

Provider engine PR here: https://github.com/MetaMask/provider-engine/pull/79

Fix for this, with tests, depends on when this can get merged.

[tcoulter]

Fixed in TestRPC v2.0.10.

[sk4092]

contractInstance.MyEvent({}, {fromBlock:0, toBlock:'latest'}).get(function(err, results){})
works fine for me but if I remove the empty parenthesis (ie. first parameter) it returns only latest event.
ie. if you use contractInstance.MyEvent({fromBlock:0, toBlock:'latest'}).get(function(err, results){})
eth apply the filter as fromBlock: latestBlockNumber