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
Currently wrapping any of these connection types is very error prone. We've run in to interface assertion errors a bunch of times around these connections.
The last few were with the introduction of the shared tcp listener for tcp and websocket.
The problem is that any wrapping breaks interface assertions downstream.
Most recently, when implementing #3186 I ran into it again when the tcp.tracingListener rejected the wrapped manet.Conn as it didn't expose the tcp metrics tracing methods. Here's the code where this happens: https://github.com/libp2p/go-libp2p/blob/master/p2p/transport/tcp/metrics.go#L292
If we add Unwrap() Conn methods to the most used types(manet.Conn, transport.Conn, network.Conn), similar to the Unwrap() []error method on error wrappers, we will have an idiomatic way of asserting if any connection in the whole wrapping chain implements the expected method.
This will still be brittle. It depends on correctly implementing Unwrap always. But it should be better than the situation right now.
The text was updated successfully, but these errors were encountered:
Currently wrapping any of these connection types is very error prone. We've run in to interface assertion errors a bunch of times around these connections.
The last few were with the introduction of the shared tcp listener for tcp and websocket.
The problem is that any wrapping breaks interface assertions downstream.
Most recently, when implementing #3186 I ran into it again when the
tcp.tracingListener
rejected the wrappedmanet.Conn
as it didn't expose the tcp metrics tracing methods. Here's the code where this happens: https://github.com/libp2p/go-libp2p/blob/master/p2p/transport/tcp/metrics.go#L292If we add
Unwrap() Conn
methods to the most used types(manet.Conn
,transport.Conn
,network.Conn
), similar to theUnwrap() []error
method on error wrappers, we will have an idiomatic way of asserting if any connection in the whole wrapping chain implements the expected method.This will still be brittle. It depends on correctly implementing Unwrap always. But it should be better than the situation right now.
The text was updated successfully, but these errors were encountered: