When the incoming messages not coming by order, the async protocol may stuck at the last round forever.
For example, there is a protocol has 2 rounds, when the messages for the round 2 are coming first before the messages for round 1. All these messages will be saved in the message store inside the state machine. When the messages for round 1 are ready, the protocol will go to round 2. But at this time, the handle_incoming().await in the loop may never get the messages for the last round (round 2), cause they are already saved inside the state machine.
I found this issue, when I was debug a strange issue for multi-party-ecdsa. I found that when there was a lot messages and the message channels were busy, some of the async protocol may never finish the last round.
I've changed the proceed_if_needed method a little bit, make the state forward as much as it can to avoid the issue.
When the incoming messages not coming by order, the async protocol may stuck at the last round forever.
For example, there is a protocol has 2 rounds, when the messages for the round 2 are coming first before the messages for round 1. All these messages will be saved in the message store inside the state machine. When the messages for round 1 are ready, the protocol will go to round 2. But at this time, the
handle_incoming().await
in the loop may never get the messages for the last round (round 2), cause they are already saved inside the state machine.https://github.com/ZenGo-X/round-based-protocol/blob/149512bb0a32805fb0f460c690a35427f10bc0e1/src/async_runtime/mod.rs#L145
I found this issue, when I was debug a strange issue for multi-party-ecdsa. I found that when there was a lot messages and the message channels were busy, some of the async protocol may never finish the last round.
I've changed the
proceed_if_needed
method a little bit, make the state forward as much as it can to avoid the issue.