Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Check Steem issue 2658: Not producing block because node didn't wake up within 500ms of the slot time #1157
Generally, if latency of previous block is too high, the node will try to produce another block on the first second of its time slot. But in the scenario when witness list got shuffled after the previous block, the node may "suddenly" find it's its turn to produce next block, but will fail as described above.
Note: this is a minor issue, IMHO low priority.
added a commit
Aug 17, 2018
referenced this issue
Aug 17, 2018
We should define desirable behaviour before implementing fixes.
IMO, if a node hasn't received a block from its predecessor when its time slot has come, it should simply produce its own block in time.
There is one special case though: if the previous block has been received in time but takes a long time to apply (as is often the case in a maintenance block), then it makes sense to produce one even if our slot is nearing its end. I would extend the deadline in that special case only.
In this issue, the node was not waiting doing nothing until it's slot is nearly over, but on the contrary, it tried to produce a block on the 2nd second and the 3rd second but failed due to the timeout check. The reason why it didn't try to produce on the 1st second, is it was not its time slot to produce before received the high-latency block, that said, the high-latency block caused a schedule change.