Node started view change for a higher view while others are voting for a lower one #4
Description
In one run, one of the nodes got impatient and started view change for 28, just after it got a StartViewChange message for 27. In fact, it even sent out StartViewChange for 27 to other nodes. However, the view timer still expired and triggered a StartViewChange for 28.
Seems like this could be due to CPU scheduling and there's really nothing we could do about it. This behavior could happen in production too, but it's just not efficient.