Description
In #4777, we discovered that a "connection management" behaviour like libp2p-connection-limits
can lead to inconsistent state if it is not applied "first" in the tree of behaviours.
That is because the handle_
functions take &mut self
and thus allow modifying the state of a NetworkBehaviour
, potentially pre-loading a handler with state. If a behaviour deeper in the tree ends up rejecting the connection, that state is lost.
Preloading handlers is useful to ensure they don't "instant timeout" based on keep-alive after a connection has been established.
The underlying design issue here is that the composition of handle_
functions leads to an inconsistent view across the state of NetworkBehaviour
s. By having them take &self
, this issue would not occur (unless the user users internal mutability but that we can't guard against).
Somehow, we'd need to find a way to still pass data to the handler but only in case the connection is fully established. Perhaps we should find a way to mitigate the "instant shutdown" in a different way by not starting the Connection
task until the ConnectionEstablished
event has been dispatched to the behaviour?