We are sending control extensions messages using the current implementation of GossipRpcPartsQueue. We need to investigate the scenario where we have on the queue both a control extension message enabling a particular extension X, and a X extension message.
In the case of splitting, if the X extension message ends up being sent first, we might have an issue where the peer won't know we support that extension because the control extension message with the flag for X support will be sent later.
Questions:
- Can this happen in practice?
We are sending control extensions messages using the current implementation of
GossipRpcPartsQueue. We need to investigate the scenario where we have on the queue both a control extension message enabling a particular extension X, and a X extension message.In the case of splitting, if the X extension message ends up being sent first, we might have an issue where the peer won't know we support that extension because the control extension message with the flag for X support will be sent later.
Questions: