How do geth and parity handle notifying clients of events after reorgs?

Question

If you set up an event listener with Geth (I assume also with Parity) you get notifications when a particular event shows up in the event logs.

Sometimes a reorg will happen, and the block where that event happened will be orphaned and disappear from the main history. The same transaction may cause an event to be raised in a different block.

Is the following correct?

• An event will always be fired when a block generating that event gets into what the node considers the main chain
• If there's a big reorg events several blocks deep will be sent out almost simultaneously
• An event will still be sent out again even if its content (aside from block hash etc) is the same, so for example if you listen for a contract that raises an event when it's paid, you may get the same event twice even though you'll ultimately only end up getting paid once

Are there any traps for the unwary or interesting implementation-specific wrinkles?

Answer 1

I believe you are correct, although I don't think I've ever tested it. Event filters in web3.js are a little strange--if you set fromBlock to earlier than 'latest', it will trigger on historical events.

Looking at the actual JSON-RPC spec, it seems that eth_getFilterChanges will actually say if an event was removed via a reorg. While I don't think the current web3.js exploits this to a large degree, a client that uses the RPC directly (shudder) could know better.