Subsequent dial with multiaddr not in the previous dialTarget

[vasco-santos]

• Version: 0.29
• Platform: *
• Subsystem: Dialer

Type: Bug

Description:

When a dial to a given peer is performed, if a dial to the same peer is currently in progress, this dial will just wait on the first to finish and return its connection.

A tricky scenario can happen with this flow. If the second dial uses an address that was not included in the first one, it will not be used. For instance, by using libp2p.dial(ma1) ... libp2p.dial(ma2), or by getting the multiaddrs from AddressBook and then dial from a not known multiaddr of a peer, the second multiaddrs will not be used.

Steps to reproduce the error:

• libp2p.dial(serverMultiaddr)
  • (exchanged identify addresses (that do not announce the serverMultiaddr))
• on reload, autoDial kicks in from peerStore
• libp2p.dial(serverMultiaddr)

Reference: ipfs/js-ipfs#3400

[vasco-santos]

On a sync conv with @jacobheun

this is where multiaddr confidence would be really nice. Maybe in the interim we could add on identify and prune known addresses when they fail a dial? This wouldn't be great for intermittent failures but we need a way to avoid storing hundreds of multiaddrs for a peer until we get confidence in place

[achingbrain]

Since #1498 when passed a multiaddr, only that multiaddr is dialed so this is no longer possible.

There's a possible edge case where if you dial a peer id, then add a new address to the address book, then dial the peer id again it may join on the first dial promise rather than adding the new address to the dial target but this needs further investigation.

[maschad]

Closing as we currently only dial one peer at a time so this is not possible