If the underlying socket is already closed during State::Closing, it is not an error to get ENOTCONN when calling shutdown, so ignore it.
This can happen when a connection is local to the host and the kernel already has shutdown the socket.
related to hyperium/hyper#3070
(with this change, i can't reproduce the behaviour there anymore)
not completely sure about also checking reason for NO_ERROR, maybe should also check intiator for Library ?
IMO this change is ok, because AFAICS this only happens when we come from handle_poll2_result where it's already noted that we're 'already going away' and it does not make sense to bubble a ENOTCONN up when trying to shutdown the connection as it's already shut down.
If the underlying socket is already closed during State::Closing, it is not an error to get
ENOTCONNwhen calling shutdown, so ignore it.This can happen when a connection is local to the host and the kernel already has shutdown the socket.
related to hyperium/hyper#3070 (with this change, i can't reproduce the behaviour there anymore)
not completely sure about also checking reason for
NO_ERROR, maybe should also check intiator forLibrary?IMO this change is ok, because AFAICS this only happens when we come from
handle_poll2_resultwhere it's already noted that we're 'already going away' and it does not make sense to bubble a ENOTCONN up when trying to shutdown the connection as it's already shut down.