Update peer socket address when peer already existsRefresh the stored address if an existing peer is added again #735
Conversation
|
I've assigned @tnull as a reviewer! |
|
🔔 1st Reminder Hey @tnull! This PR has been waiting for your review. |
|
🔔 2nd Reminder Hey @tnull! This PR has been waiting for your review. |
|
|
||
| if locked_peers.contains_key(&peer_info.node_id) { | ||
| return Ok(()); | ||
| match locked_peers.get_mut(&peer_info.node_id) { |
There was a problem hiding this comment.
I'm not sure why we bother to first look it up if the following behavior is identical to insert anyways? Why then not just always insert?
| pub(crate) fn add_peer(&self, peer_info: PeerInfo) -> Result<(), Error> { | ||
| let mut locked_peers = self.peers.write().unwrap(); | ||
|
|
||
| if locked_peers.contains_key(&peer_info.node_id) { |
There was a problem hiding this comment.
We can't just drop this, as there are instances where we'd add_peer but don't want to override the peer address if we already have one (e.g., when adding peers for inbound channels in event.rs). To solves this, we should probably just introduce an override: bool flag that lets us not return early. Alternatively, we could have two different methods for updating or inserting a peer.
3 participants
Fixes #700.
Previously, re-adding an existing peer would return early and ignore an
updated socket address, causing stale peer addresses to be persisted.
This change updates and persists the peer info when the address differs,
and adds a regression test covering the behavior.