When importing new blocks Parity goes into sync mode very briefly, giving false ethstats info

[jleeh]

I'm running:

• Which Parity version?: 1.11.8
• Which operating system?: Linux
• How installed?: Docker
• Are you fully synchronized?: yes
• Which network are you connected to?: Ethereum & Ropsten
• Did you try to restart the node?: yes

This issue is only seen in 1.11.8, and not in any of the previous versions.

Upon upgrading to 1.11.8, I noticed that our Parity nodes are reporting large block propagation times occasionally. These block propagation times would always equal the time it taken to get the next block, which raised my suspicion there was an issue.

This can be seen on https://ethstats.net/. If you look at all the Parity 1.11.8 nodes, they mostly all have large spikes in propagation times.

---

Upon investigating, it seemed that all the nodes that were reporting to not have the latest block did actually have the latest block and were reporting the correct block number when ethstats said they weren't.

This caused me to investigate into the eth-net-intelligence-api, and see what could be happening to cause this. Line 720 in the node.js file:
https://github.com/cubedro/eth-net-intelligence-api/blob/master/lib/node.js#L720

There's only one way the service can miss a new block, and that's if a Parity node goes into sync mode and then comes out of it straight away. This is due to the blocknumber only being updated when syncing is actively in progress, if a node comes straight back out of sync then it only then listens for further new blocks.

This aligns with what is being seen in ethstats, with the wrong blocknumber being reported until a further new block comes in.

---

To test this theory, I sat spamming up + enter with eth.syncing in the Geth JS console:

> eth.syncing
false
> eth.syncing
false
> eth.syncing
false
> eth.syncing
{
  currentBlock: 6228721,
  highestBlock: 6228721,
  startingBlock: 6206171,
  warpChunksAmount: null,
  warpChunksProcessed: null
}
> eth.syncing
false
> eth.syncing
false

The above output is from when the Parity instance just starts reporting a wrong blocknumber on ethstats. The duration between each of the eth.syncing commands is milliseconds, as fast as I can hit up + enter.

[andresilva]

I think the only thing that went into 1.11.8 that could affect this is #9112. I'll investigate.