feat(peer-exchange): support continuous peer information updates #2088
Conversation
size-limit report 📦
|
|
|
||
| const existingMas = peer.addresses.map((a) => a.multiaddr.toString()); | ||
| const newMas = peerInfo.multiaddrs.map((ma) => ma.toString()); | ||
| const hasMaDiff = existingMas.some((ma) => !newMas.includes(ma)); |
There was a problem hiding this comment.
What happens if newMas has a multiaddr that's not in existingMas?
There was a problem hiding this comment.
We patch the Peer Store with the new multiaddrs (overwrite these), as that would imply the older addresses are now invalid, thus replacing with the new ones
| }), | ||
| ...(hasShardDiff && | ||
| shardInfo && { | ||
| metadata: { |
There was a problem hiding this comment.
will it replace previous value of metadata or will it combine them?
also, if transition happens from shardInfo={...} to shardInfo=null - should it be erased from peerStore?
There was a problem hiding this comment.
using patch will replace all existing metadata, might be better to use merge here
There was a problem hiding this comment.
will it replace previous value of
metadataor will it combine them?also, if transition happens from
shardInfo={...}toshardInfo=null- should it be erased frompeerStore?
Yes: #2088 (comment)
using
patchwill replace all existing metadata, might be better to usemergehere
Good point about that. We only use metadata for shardInfo and TAGS for now, but merge is a better option here. Thank you! :D
packages/discovery/src/peer-exchange/waku_peer_exchange_discovery.ts
Outdated
Show resolved
Hide resolved
packages/discovery/src/peer-exchange/waku_peer_exchange_discovery.ts
Outdated
Show resolved
Hide resolved
db0de08 to
44215b3
Compare
Problem
In a case where Peer Exchange discovers a peer, and stores its information including shard it supports & the listening multiaddresses it has, when and if the same peer is discovered again, we check for its presence in the Peer Store and if it exists we don't take any action.
This can be problematic as discovered in waku-org/go-waku#1128, where the peer discovered again MIGHT have new shard information it supports, or new listening addresses, while having the same peer ID (essentially being seen as the same peer)
Solution
Once the peer is discovered again, do a check on the information received by Peer Exchange in respect to the shard information and multiaddrs received now, and compare it with information we have in the Peer Store -- this will guide us to either patching the Peer Store with new updated information, or continuing with confirmation nothing changed.
Also adds tests for updated shard information & listening addresses.
Notes
Contribution checklist:
!in title if breaks public API;