I am running in a private chain (v1.3.3), go ethereum. Sometimes (it is recreateable) eth_getFilterChanges will return duplicate events. I have a fair amount of detail for you, so hopefully the following is clear. I have 2 go threads, each thread is tracking a different contract address. Each thread wakes up every 15 seconds and calls eth_getFilterChanges. Sometimes (maybe once an hour?) the response to that API call will return duplicate events. That is, only 1 event has occurred on the blockchain but the API returns an array of 2 events, dup of each other. These are events that my contract creates as it runs. Here's something interesting. In one instance of the problem, both threads saw duplicate events in the EXACT SAME BLOCK. My 2 contracts do call each other, so it makes sense that both contracts will have an event in the same block but there shouldnt be duplicates. This seems interesting to me because this is happening from 2 different calls (remember I have 2 threads) to the eth_getFilterChanges API (using different filter ids), so this says to me that the duplicate events are not a problem with the API itself but seem to have something to do with the block state that the events are in.
Here's another interesting thing to note. I blew away my geth client's local state (db, ethash etc), restarted it, allowed it to resync to the chain, then I started my threads again. When the threads dumped events for the block in question (this time using eth_getFilterLogs), there were NO duplicate entries. So, whatever block state was confused previously, was resolved by the restart. Further, this also tells me that the dup events DO NOT exist in the blockchain, again it seems to have something to do with the local block state from which get_ethFilterChanges derives it's data.
In order to try to help resolve this issue, I created a scaled down testcase. I've attached a geth log, a log from my RPC client, my RPC client code, and my solidity file inside the zip file. You probably wont be able to run the program directly because I havent provided all the other libraries but you will be able to clearly see what's going on in the testcase.
event-defect.zip
I am running in a private chain (v1.3.3), go ethereum. Sometimes (it is recreateable) eth_getFilterChanges will return duplicate events. I have a fair amount of detail for you, so hopefully the following is clear. I have 2 go threads, each thread is tracking a different contract address. Each thread wakes up every 15 seconds and calls eth_getFilterChanges. Sometimes (maybe once an hour?) the response to that API call will return duplicate events. That is, only 1 event has occurred on the blockchain but the API returns an array of 2 events, dup of each other. These are events that my contract creates as it runs. Here's something interesting. In one instance of the problem, both threads saw duplicate events in the EXACT SAME BLOCK. My 2 contracts do call each other, so it makes sense that both contracts will have an event in the same block but there shouldnt be duplicates. This seems interesting to me because this is happening from 2 different calls (remember I have 2 threads) to the eth_getFilterChanges API (using different filter ids), so this says to me that the duplicate events are not a problem with the API itself but seem to have something to do with the block state that the events are in.
Here's another interesting thing to note. I blew away my geth client's local state (db, ethash etc), restarted it, allowed it to resync to the chain, then I started my threads again. When the threads dumped events for the block in question (this time using eth_getFilterLogs), there were NO duplicate entries. So, whatever block state was confused previously, was resolved by the restart. Further, this also tells me that the dup events DO NOT exist in the blockchain, again it seems to have something to do with the local block state from which get_ethFilterChanges derives it's data.
In order to try to help resolve this issue, I created a scaled down testcase. I've attached a geth log, a log from my RPC client, my RPC client code, and my solidity file inside the zip file. You probably wont be able to run the program directly because I havent provided all the other libraries but you will be able to clearly see what's going on in the testcase.
event-defect.zip