When failing to establish WebRTC connection a "half open" connection can occur

[marcus-pousette]

• Version:
  libp2p 1.8.2
  libp2p/webrtc 4.1.3
  libp2p/circuit-relay-v2 1.1.3

• Platform:
  23.0.0 Darwin Kernel Version 23.0.0: Fri Sep 15 14:41:43 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6000 arm64. Version 1.64.109 Chromium: 123.0.6312.58 (Official Build) (arm64)

• Subsystem:
  Circuit Relay, WebRTC

Severity:

Medium/High

Description:

I am investing issues I am having when using the WebRTC transport between nodes in offline mode, and I seem to end up in a unexpected state sometimes when a WebRTC connection is failing to establish, but only one side realizes this.

My main concern with this issue is that WebRTC connections could fail out in the wild (for other reasons than the reproduction method below) and if that leads to bad user experience

Steps to reproduce the error:

When using this example (update all dependencies or use them as is)

https://github.com/libp2p/js-libp2p-examples/tree/main/examples/js-libp2p-example-browser-pubsub

Turn WIFI off completely on your computer (this seems to disable WebRTC connections to be establish at all even if you connect to another node on the same machine).

Now run the example with two nodes and try to connect them to each other (one connects to the relay, the other one connects to the webrtc address of the first node).

Connected peers on the first node only shows the relay node (1 connection in total), expected because it failed to establish a WebRTC connection.

BUT the node that is dialing never realizes that something wrong has happened (!) and still shows that it is connected to both the relay and the WebRTC connection (2 connections in total).

The expected outcome is that both nodes realizes that the WebRTC connection was never establish.

....
In earlier version of libp2p (1.0.8 (?)) (the version that is now in the (js-libp2p-example-browser-pubsub)) you will get an error message that indicates that the WebRTC connection was aborted without reason on the first node, but I am leaving that out of the description here since it might not apply 1.8.2. But the outcome is the same in the end

[achingbrain]

That's interesting, I think something like #2644 would help here, at least in that it'd clean up dead/stuck connections after a short time.

We should be able to handle this scenario better though.