flaky examples/relay tests

[marten-seemann]

 === RUN   TestMain
      logharness.go:101: saw: Okay, no connection from h1 to h3: no addresses
      logharness.go:106: did not see expected prefix "Meow! It worked!"
  --- FAIL: TestMain (4.54s)

[marten-seemann]

The problem here is the following:
h1 and h3 connect to h2 (the relay). As soon as both of them have established a connection via to the relay, they try to establish a connection between each other via the relay. This is racy, as both h1 and h3 might dial using multiple transports, (temporarily) resulting in the establishment of multiple connection. Spurious connections will then be closed by the respective hosts. Now it might happen that the connection attempt between h1 and h3 happens before the relay learns which connection is closed.

[Stebalien]

Really? IIRC, we don't close these connections anymore.

[Stebalien]

Or is this because we're canceling outbound dials once one dial succeeds? I believe we can fix this in

go-libp2p/p2p/host/basic/basic_host.go

Line 602 in e70d7cf

case <-h.ids.IdentifyWait(s.Conn()):

by trying to create a new stream if identify fails... maybe?

[marten-seemann]

Or is this because we're canceling outbound dials once one dial succeeds?

Yes: https://github.com/libp2p/go-libp2p-swarm/blob/88ef86a16cf0bbc451c3799f63278d345aaf56ea/limiter.go#L227-L234

by trying to create a new stream if identify fails... maybe?

Not sure if I understand your proposal. h2 is creating a stream to h3 (for relaying the connection from h1 to h3). Where does identify come into play here?

[Stebalien]

Well, it's kind of a hack, but it's not too terrible. Basically, if peer A successfully "identifies" peer B, peer B must have yielded the connection to the host and therefore won't cancel it.