void

[ghost]

moved to: https://github.com/lazaridiscom/parity-ethereum/issues/2

[jam10o-new]

https://github.com/paritytech/parity-ethereum/blob/dae5d75dd65d6a51873ecd9c1c4f159f49f2a9f3/ethcore/blockchain/src/blockchain.rs#L1049-L1056

You can see the important functions here, a route is created and then the block is inserted with the route - the blockchain reevaluates the best_block every insertion.

[jam10o-new]

The sentiment among the core-devs seems to be that this train of though is a little counterproductive.

To elaborate we shouldn't be treating existing blocks as invalid after importing them in any case, as that would mean we imported them without validation at some point, any further chains built on top are ignored. More succinctly -> #10085 itself is the issue we should be looking into solving as it gets us into a scenario we explicitly don't want to handle, we should be fixing that, not handling the repurcussions of it afterwards.

[dvdplm]

So, I've tried to use the repro code to see if it can help us pinpoint the problem and unfortunately I cannot trigger the error. Blocks #6942 and #6943 seem to be imported properly and while #6882 does cause 2019-06-06 18:55:43 UTC Verifier #2 TRACE blockchain #6882 0x28fd…5a04 - 0x273b…0377 HASH UNEQUAL, #6882 it does not trigger a panic or error.

Not sure if I'm doing something wrong here or if the repro does not work on all hosts or…?