You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found this when adding an integration test for QUIC version support as part of #1905. The test above should be added as an integration test.
It probably makes the most sense to work on a fix for this on top of #1905.
As I started fixing this I realized that I was writing special logic in the swarm to handle listeners returning multiple (possibly changing over time) multiaddrs. This felt error-prone and like a leaky abstraction. I'm thinking now that we shouldn't have Listeners return multiple multiaddrs. This leaks the implementation detail of us using the same listener for multiple multiaddrs to the rest of the stack. This problem is highlighted in this issue because we want the Listener to only return one multiaddr (quic-draft29) until we ask the transport to give us another listener for the other multiaddr (quic-v1).
I also think this is a similar problem to the quic conn-reuse across the quic transport and WebTransport. And in that case we didn't (and shouldn't) have the quic Listener also return the webtransport multiaddr.
Because this involves potentially undoing the breaking API change we made here: #1881 that isn't released yet this is blocking issue for this next release. If we aren't sure we want this breaking change, we should avoid it.
This test fails, as the listener is listening on both versions.
The text was updated successfully, but these errors were encountered: