Downcasting axum’s error in WebSocket to original type to catch connection reset?

[silmeth]

Summary

I’ve recently moved a piece of WebSocket handling code from manual hyper + tungstenite to axum. Overall it was fairly easy and works as it did previously – but I’ve a slight problem with error handling.

Previously, when handling WS messages, we filtered out the connection reset by peer messages by checking for the error type, something along those lines:

match message {
    Ok(Message::Text(msg)) => { /* … handle messages … */ }
    // …
    Err(tungstenite::Error::Protocol(
        ProtocolError::ResetWithoutClosingHandshake,
    )) => {
        // count the disconnects but do not log this (happens often and is an expected behaviour)
        metrics
            .disconnected_ws_count
            .fetch_add(1, Ordering::Relaxed);
    }
    Err(err) => warn!(error = ?err, "Error while handling WS messages"),
}

now I just get dynamic axum::Error with the content: Error { inner: Io(Os { code: 104, kind: ConnectionReset, message: "Connection reset by peer" }) }.

I see there’s a difference of the type of error too (IO error instead of tungstenite’s Protocol error) – not sure if that’s a difference from axum’s different use of the WS, or a change between tungstenite versions.

Anyway, is there a way to cast it down to the underlying error so that I’d be able to filter it out without stringifying it and checking for substrings like ConnectionReset? Having bazillion warning logs because proxy server somewhere times out our idle connections (which we do expect to happen, the client will reconnect if it needs to) is annoying (while we would like to catch other unexpected stuff happening to the WS).

axum version

0.7.7

[silmeth]

Oh, I think I can just do err.into_inner() and then try to call downcast[_ref]::<tungstenite::Error>() on it, right? (ie., the inner error actually is the tungstenite one?)

The question still remains why it’s now Io(Os { … }) instead of Protocol(ResetWithoutClosingHandshake) though.