Geth Websocket Behavior during reorganization

Question

I have a question about the behaviour of Geth during re-org. Particularly, I am connecting to Geth web-socket to receive new blocks when they are discovered. Usually every 10 to 15 seconds I get a block message on the web-socket.

My question is what I will receive during re-org? Say a re-org of 4 blocks occurred (so the last 3 blocks I received are orphaned now, and there are 4 new blocks to me), will Geth send all the blocks at once (old/new), or it will send what exactly. I am not able to find any documentation for the above, please provide to link to documentation if you can find any.

Also please help with how to simulate/test reorg with Geth on test net.

Answer 1

For the first question, according the docs, what you get should be as follows.

Say the last 3 blocks you mentioned are called a, b, and c, and the 4 new blocks are A, B, C, D. It should be that

a, b, c, A, B, C, D

because it says

In case of a chain reorganization the subscription will emit all new headers for the new chain. Therefore the subscription can emit multiple headers on the same height.

Answer 2

If reorgs happen are you are subscribed with the PUB/SUB feature

{"id": 1, "method": "eth_subscribe", "params": ["newHeads", {}]}

You will start to get new blocks.

1, 2, 3, 4, ...

And on reorgs the same previous blocks will be returned. For example

1, 2, 3, 4, 2, 3, 4, 5, ...

Notice that 2, 3, 4 were sent a second time. This means they were reorged.

To simulate this you need to break down your code. In golang you can have a function that receives a channel with the new block numbers and completely decouple connecting to the ethereum node and receiving the nodes.

In javascript you could simulate this with a callback function, but you still need to write testable code.

Basically what I suggest is write your code to be testable and decouple reading the subscription from processing the new block. It's quite hard to simulate reorgs and it's not comfortable to mock the ethereum node. Easiest thing to do is design your code to be testable.