How to capture errors caused by clients disconnecting?

[lithbitren]

Summary

In the context of Axum, if a client terminates the TCP connection while an asynchronous operation is awaiting, how can I catch this error to facilitate handling such interrupted handlers gracefully?

Consider the following handler snippet as an example:

async fn handler(...) -> ... {
    ...
    memory += 1;
    waiting_for_20_secs().await;
    memory -= 1;
    ...
}

During testing with reqwest, if I forcefully terminate the client using ctrl+c, the subsequent operations in the server-side handler are abandoned. I'm looking to capture an error in these situations to properly manage resources or clean up after such client disconnections.

axum version

axum = "0.7.5"

[mladedav]

You'll want to use a drop guard that does the decrement on drop.

Note that there are is no async drop so if you need to do something more complicated, you might have a cleanup task and just notify it from the drop guard about new cleanup work.

[lithbitren]

It's plausible to implement a middleware for monitoring handler execution completeness, but I'm more interested in understanding why a handler didn't finish, akin to how a timeout middleware operates. With a HandleErrorLayer, errors can be captured, indicating if the handler was terminated due to a timeout, for instance.

    .layer(
        ServiceBuilder::new()
            // `timeout` will produce an error if the handler takes
            // too long so we must handle those
            .layer(HandleErrorLayer::new(handle_timeout_error))
            .timeout(Duration::from_secs(30))
    )

[mladedav]

I'm not exactly sure what you mean, but note that your middlewares won't be polled either, just their drop implementations.

Notably, since the connection has been closed, it makes no sense for your handler/layer to return either a response or an error (that would be turned into a response).

Maybe try describing what you're trying to achieve and we can try to figure that out?

[lithbitren]

For instance, I want to monitor the real-time number of active connections for certain handlers, and based on that, calculate the maximum number of connections. The middleware logic is straightforward: increment an atomic counter before starting a handler and decrement it after the handler finishes. However, complications arise when a client disconnects while waiting for external I/O; in this case, Axum cancels the coroutine, leading to the connection counter increasing without ever being decreased.

Of course, if the counter doesn't reset to zero when there are no active connections, one could infer how many handlers closed abnormally. But I can't definitively conclude whether these handlers closed solely due to TCP disconnections.

On another note, this issue doesn't surface in actix-web. Although actix-web also doesn't report connection errors, it does execute the entire handler even if the TCP connection is severed, ensuring the counter middleware's statistics remain accurate.

[mladedav]

You can use a drop guard in the middleware. Increment before calling a handler, decrement in Drop implementation of the guard.

This is a tradeoff, if we polled the handler (and all its middlewares) to completion, we'd be wasting resources only to discard the response later.