Parity-ethereum: Question: How do geth and parity handle notifying clients of events after reorgs?

[phleemac]

Come across this: http://ethereum.stackexchange.com/questions/10586/how-do-geth-and-parity-handle-notifying-clients-of-events-after-reorgs/10587 while searching for answer of the same question.

Could you please provide the answer to that question? I also suggest to document the expected reorg behaviour in the api spec i.e. https://github.com/ethcore/parity/wiki/JSONRPC

In addition to that question, I also wonder what's the behaviour of block and pending transaction filters in case of chain reorgs: e.g.

• will block filter return the same block hash again when it become orphaned (I assume not from the current api as, unlike log filter in geth, it doesn't provide a 'removed' field)?

• will pending transaction filter return the same transactions again when they are re-included in some new block in case of re-orgs?

Same question posted to geth: https://github.com/ethereum/go-ethereum/issues/3578

[5chdn]

I'm tempted to close this as _stale_ unless someone answers this question on reorg notifications.

@paritytech/core-devs Please assign this issue to someone and decide on a deadline within 7 days, thanks. Also, check if this one is a related question: #1899

[tomusdrw]

A note: Pub-Sub newHeads subscription is handling re-orgs correctly (notifies about all new blocks becoming cannonical), from 1.7 I would recommend to use this instead of filters.

[charles-cooper]

Hello,
Is this behavior documented anywhere? If not, what is the current behavior?

[joshua-mir]

@charles-cooper https://wiki.parity.io/JSONRPC-eth_pubsub-module#eth_subscribe

[charles-cooper]

@joshua-mir Thanks for the pointer! I looked through the reference but I'm still unclear about the behavior in the presence of reorgs. Is it possible to clarify?

[joshua-mir]

@charles-cooper, you'll see a group of newHeads coming in at once, you can tell that it's a reorg because "number" (block number) will have decreased for most blocks compared to previous blocks.

[tomusdrw]

@charles-cooper as @joshua-mir said, newHeads subscription emits all headers that are enacted - i.e. we believe they are now part of the canon chain.
So in case of reorgs you will first get a notification for header N and then another notification for the same number N but with a different header.

So a reorg happen if you receive a head notification for block number that is lower or equal to the one received earlier.

Relevant code:
https://github.com/paritytech/parity/blob/70de76595f3b16ff87e58d0461bc50848645369b/rpc/src/v1/impls/eth_pubsub.rs#L224-L239
and
https://github.com/paritytech/parity-ethereum/blob/70de76595f3b16ff87e58d0461bc50848645369b/ethcore/src/client/chain_notify.rs#L74-L93

[charles-cooper]

@joshua-mir @tomusdrw thanks for clarifying! It looks also like logs get 'removed' set to true. I assume that they are 'unplayed' in reverse order before the new logs get played?

[tomusdrw]

@charles-cooper yes, the logs get removed set to true if they are part of the chain that is retracted (i.e. becomes non-canon now). I wouldn't rely on ordering though, it's not strictly specified that they are sent in reverse order. I believe currently it's going to be ascending order of block numbers + ascending order of logs within transactions (so not reverse, but rather same) and enacted&retracted notifications will be interleaved.