In a channel game, it may happen that an off-chain message is received from the peer that is for a reinitialisation which is not yet known locally; for instance, if the peer sends an auto move as soon as the channel is created on-chain, and we receive the off-chain message for that before our GSP processes the on-chain update. In this situation, we used to discard the off-chain message (which would stall the game until a dispute and resolution was done in the worst case). This issue was also causing the reorg.py Xayaships regtest to be flaky.
This set of changes introduces proper handling for this situation (as well as some other fixes, e.g. to reorg.py in general). If we now receive an off-chain message for an unknown reinit, we keep it in memory and try to process it as soon as a matching reinit is created on-chain. The total size of this cache is limited (to 100, which is more than enough in practice for fixing such an edge case) so that a bad peer cannot DoS us by filling the memory.
In a channel game, it may happen that an off-chain message is received from the peer that is for a reinitialisation which is not yet known locally; for instance, if the peer sends an auto move as soon as the channel is created on-chain, and we receive the off-chain message for that before our GSP processes the on-chain update. In this situation, we used to discard the off-chain message (which would stall the game until a dispute and resolution was done in the worst case). This issue was also causing the
reorg.pyXayaships regtest to be flaky.This set of changes introduces proper handling for this situation (as well as some other fixes, e.g. to
reorg.pyin general). If we now receive an off-chain message for an unknown reinit, we keep it in memory and try to process it as soon as a matching reinit is created on-chain. The total size of this cache is limited (to 100, which is more than enough in practice for fixing such an edge case) so that a bad peer cannot DoS us by filling the memory.