@jacobheun similarly to what we experienced in webrtc, there is a test failing here from interface-transport: abort while reading throws AbortError. The next test also fails, but it is because of side effects created from the test before.

So, I believe that there is a bug in alanshaw/stream-to-it/ using toIterable. Since we did not support abortables before, should we skip the test for now and create an issue? I think there is no need in blocking this PR with the abortable feature.

So, I believe that there is a bug in alanshaw/stream-to-it/ using toIterable. Since we did not support abortables before, should we skip the test for now and create an issue? I think there is no need in blocking this PR with the abortable feature.

This seems to be the type of error that will haunt us for life (been there, had to open many cans of worms).

To move forward, there should be a reproducible test case (or test cases) that show this behavior on the stream-to-it module and a respective comment (and issue describing the situation) on the transports (this and WebRTC) that that test needs to pass in order for the tests here to pass.

I created some tests in stream-to-it using the abort controller, but I can get it to work there 🤔

vasco-santos/stream-to-it@872e44b

In this case here, after the abort is performed, the dialer connection receives the close event. However, it-pipe does not throw an error like in libp2p-tcp/ libp2p-websockets

However, it-pipe does not throw an error like in libp2p-tcp/ libp2p-websockets

Consider creating a test with libp2p-tcp/websockets in stream-to-it to ensure that error gets caught.

With libp2p-websockets we do not use stream-to-it as we do not need the conversion. That's why I am (or was 🤔) suspecting on an issue within the module. But doesn't seem to be the case

In libp2p-tcp it uses stream-to-it and the error is caught, otherwise it would not pass the interface-transport tests

I'm looking into it, it should work. I think there is just some order of operations issue ending the connections that's causing them to stay open.

There may be some issues with utp-native. Oddly, the outbound connection emits the close event right after sending data, but the socket properties indicate that it's actually readable and writable and it thinks it's destroyed.

So, I believe the problem is that utp-native is overriding destroy on the readable-stream, https://github.com/mafintosh/utp-native/blob/v2.1.4/lib/connection.js#L206, it should be using _destroy per nodejs guidelines. Since Stream is not performing destroy properly, we never get the propagation to the iterators.

I did a quick hack locally of utp-native to use the following and things are passing for me locally. (These changes aren't verified against the rest of the utp-native code)

Connection.prototype._destroy = function (err, cb) {
  if (this._needsConnect) {
    process.nextTick(onbindingclose, this)
    return cb(err)
  }
  binding.utp_napi_connection_close(this._handle)
  cb(err)
}