fix(rpc): rpc crashes when a peer has no addresses #1507
Conversation
alrevuelta
force-pushed
the
fix-rpc-crash-peers
branch
from
e728032 to
46fde4e
Compare
There was a problem hiding this comment.
This API definitely needs a revision and dates back from when we had much cruder peer management. However, I'd split the API change from the necessary fix for crashing with no multiaddrs. Without changing the API (i.e. WakuPeer still only has a single protocol field), we could assume that all peers in the peerStore are WakuRelayCodec peers and that the peers in the service slots (post #1473) are for the protocols specified there even if we repeat them in the output.
Reasoning: the API change will require an RFC update, informing clients and changing some infra scripts, whereas we could first fix the bug.
waku/v2/node/jsonrpc/admin_api.nim
Outdated
| let connectedPeers = node.peerManager.peerStore.peers.filterIt(it.connectedness == Connectedness.Connected) | ||
| wPeers.insert(connectedPeers.mapIt(WakuPeer(multiaddr: constructMultiaddrStr(it), | ||
| identifyProtocols: it.protos, | ||
| connectedProtocol: "TODO", | ||
| connected: true))) | ||
|
|
||
| let notConnectedPeers = node.peerManager.peerStore.peers.filterIt(it.connectedness != Connectedness.Connected) |
There was a problem hiding this comment.
For interest's sake, why would this need to be split into two steps and not just map all peers from the peerStore.
There was a problem hiding this comment.
yep indeed thanks!
| @@ -29,7 +29,8 @@ type | |||
|
|
|||
| WakuPeer* = object | |||
| multiaddr*: string | |||
| protocol*: string | |||
| identifyProtocols*: seq[string] | |||
| connectedProtocol*: string | |||
There was a problem hiding this comment.
Presumably some peers could be connected for more than one protocol or would you return those peers twice?
There was a problem hiding this comment.
Right now we only allow 1 max connection per peer. So shouldnt be the case.
There was a problem hiding this comment.
Can't we have multiple protocol streams per connection? How do Status go-waku nodes for example connect to fleet nodes as their main bootstrap relay connection, but use those same nodes for store, filter and lightpush (presumably without disconnecting each time)?
There was a problem hiding this comment.
mm yeah good point. guess they are multiplexed under the same connection so connectedProtocol didnt really made sense. should be more like []protocolStreams idk. But note that with the current public method/variables in nim-libp2p we can't really get that afaik.
alrevuelta
force-pushed
the
fix-rpc-crash-peers
branch
from
46fde4e to
eb6ce84
Compare
Closes #1505
Summary:
get_waku_v2_admin_v1_peerswas crashing the node when a given peer contained no multiaddress ([0]out of bound)[0]in an empty seq.