multiple connections opened for the same peer

[danisharora099]

This is a support request

Problem

Instance:
js-waku is discovering the same peer, from two sources (possibly diff multiaddr?). Due to this, there are two dial requests, and websocket connections opening, for the same peer.

The first multiaddr comes from DNS Discovery, while the 2nd comes from parsing the multiaddr of the peer after its connection, and saving it in local storage for easier reconnection the next time.

Websocket URL 1: wss://node-01.gc-us-central1-a.wakuv2.prod.statusim.net:8000/p2p/16Uiu2HAmVkKntsECaYfefR1V2yCR79CegLATuTPE6B9TxgxBiiiA
Websocket URL 2: wss://node-01.gc-us-central1-a.wakuv2.prod.statusim.net:8000/

Expected

js-waku should only open one websocket connection to one peer

[danisharora099]

should we move this issue as part of the peer management milestone, or out of scope for the first iteration of the milestone?
cc @fryorcraken

[fryorcraken]

I would add that to #914 yes

[danisharora099]

moving this ticket to 'TODO' as it's already part of #914 which is priority/in progress

[danisharora099]

updates:

instead of this issue being tracked in #914, this should be a part of #1463:

• individual discovery classes (PeerExchange and DNSDiscovery) already factor in no redials for the same peer.
• The error originated since with the experiment of using peers from LocalStorage which does not have this control-check.
• while unrelated to this particular issue, fix: don't dial discovered peers if have already been attempted dial #1657 should address dial of these peers for manual discovery processes, or through the use of waku.dial()
• With work on feat: SDK for redundant usage of filter/lightpush #1463 where we should introduce the local storage module as a discovery class of sorts, or incorporate similar behaviour to control-check dial of peers that already exist in PeerStore

[chair28980]

@danisharora099 please add this issue to #1463 items per discussion 2024-01-04