-
Notifications
You must be signed in to change notification settings - Fork 38
Conversation
23495cf
to
908e12e
Compare
needs rebase |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some of the global peer stuff combined with individual peer connections/lists seem to be intertwined still unless I'm wrong. I wish there was an easier way to test and ensure we have multi node support.
src/node.rs
Outdated
@@ -385,24 +392,31 @@ impl Node { | |||
continue; | |||
} | |||
|
|||
let peer_connections = connect_persister.list_peer_connection_info(); | |||
let peer_connections = get_all_peers().await.unwrap_or_default(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isnt this going to pull in peers that all nodes have saved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes but on line 401 we filter out ones that our node isn't included in
d8bf270
to
5900c73
Compare
pub async fn list_peers(&self) -> Result<Vec<MutinyPeer>, MutinyError> { | ||
let nodes = self.nodes.lock().await; | ||
let peer_data = gossip::get_all_peers().await?; | ||
|
||
// get peers saved in storage | ||
let mut storage_peers: Vec<MutinyPeer> = nodes | ||
let mut storage_peers: Vec<MutinyPeer> = peer_data | ||
.iter() | ||
.flat_map(|(_, n)| n.persister.list_peer_connection_info()) | ||
.map(|(pubkey, connection_string)| MutinyPeer { | ||
pubkey, | ||
connection_string, | ||
.map(|(node_id, metadata)| MutinyPeer { | ||
// node id should be safe here | ||
pubkey: secp256k1::PublicKey::from_slice(node_id.as_slice()) | ||
.expect("Invalid pubkey"), | ||
connection_string: metadata.connection_string.clone(), | ||
alias: metadata.alias.clone(), | ||
color: metadata.color.clone(), | ||
label: metadata.label.clone(), | ||
is_connected: false, | ||
}) | ||
.collect(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wait this could just be a side effect with a bug (or not intended behavior) with our existing API. We're just doing a normal list_peers
, but perhaps we should change the API to indicate a specific node and the peers that node should be connected to?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seperating node and general peers is difficult and unsure if we should be doing that anyways, but existing behavior so not something for this to solve or get hung up on. Nice work, looks good to me!
needs rebase |
I also moved the peer connection info to indexedDB.
TODO: