fix nodes panic during synchronization #5081
Conversation
|
Thanks for looking into this.
|
I was thinking about synchronous writing, but as I think the idea here was to parallele getting the next block from puller and writing the current one to state. That is a time saver. |
I'm at work on a test. |
we do get the next block from the remote node though, whether you are doing a sync write or an async one. Because when you retrieve a block from the sync buffer, a new block is fed into it. |
pfi79
force-pushed
the
fix-sync-bft
branch
2 times, most recently
from
fdb6cf8 to
315657f
Compare
Signed-off-by: Fedor Partanskiy <fedor.partanskiy@atme.com>
|
I know that you didn't provide a test, but I am perfectly fine with using the sync block writing when we synchronize. |
#5076
What's going on?
During synchronisation, the synchroniser reads blocks from another node and writes them to itself.
Block writes are started asynchronously, and we have no control over when this goroutine will actually be executed.
Without waiting for the block to be written, the synchroniser proceeds to the next step.
When finished, the synchroniser exits and the code immediately detects that the node has not reached altitude and enters a new synchronisation cycle.
The
startHeight := s.Support.Height()method is executed as the start of the range to synchronise. But it happens that the previous block has not been written yet (but will be soon) and we choose the number of the block that is about to be written as the start. Thus it is possible to write two identical blocks in a row.Proposal
Set block recording to synchronous mode