Actix socket not closing properly "TCP localhost:http-alt->localhost:56785 (CLOSE_WAIT)"

[shanithkk]

Expected Behavior

The established connect should close. not in close_wait state

Current Behavior

"TCP localhost:http-alt->localhost:56785 (CLOSE_WAIT)"
it is going in CLOSE_WAIT state

Possible Solution

Steps to Reproduce (for bugs)

1. Run the example given in doc
2. check the process connection (lsof -p )
3. connect ws via postman or any
4. check agian the process connection (lsof -p )
5. close the connection
6. check again the process connection (lsof -p ). will see " "TCP localhost:http-alt->localhost:56785 (CLOSE_WAIT)"

Context

Your Environment

• Rust version (output of rustc -V):
• actix-ws crate versions: 0.30.0, also with direct git url

[Ptijohn]

Hi!
We were going to open a new ticket, but it seems that this issue is the same as what we've observed. Namely that closing abruptly the connection to a websocket (that uses actix-ws 0.30.0) doesn't close it on the server side.

We've created a simple reproducible example of that behavior. Here it is:

use std::io;

use actix_web::{App, Error, HttpRequest, HttpResponse, HttpServer, middleware, web};
use actix_ws::Message;
use futures_util::StreamExt;
use tokio::task::spawn_local;

#[tokio::main(flavor = "current_thread")]
async fn main() -> io::Result<()> {
    env_logger::init_from_env(env_logger::Env::new().default_filter_or("trace"));

    log::info!("starting HTTP server at http://localhost:8080");

    HttpServer::new(move || {
        App::new()
            // websocket route
            .service(web::resource("/ws").route(web::get().to(
                async |req: HttpRequest, stream: web::Payload| -> Result<HttpResponse, Error> {
                    let (res, session, msg_stream) = actix_ws::handle(&req, stream)?;

                    // spawn websocket handler (and don't await it) so that the response is returned immediately
                    spawn_local(loop_on_messages(session, msg_stream));

                    Ok(res)
                },
            )))
            // standard middleware
            .wrap(middleware::Logger::default())
    })
    .workers(1)
    .bind(("127.0.0.1", 8080))?
    .run()
    .await
}

pub async fn loop_on_messages(mut session: actix_ws::Session, msg_stream: actix_ws::MessageStream) {
    log::info!("connected");

    let mut msg_stream = msg_stream.max_frame_size(128 * 1024);

    while let Some(Ok(msg)) = msg_stream.next().await {
        log::info!("msg: {msg:?}");

        match msg {
            Message::Ping(bytes) => {
                session.pong(&bytes).await.unwrap();
            }

            Message::Text(text) => {
                log::info!("Here's the text {text}");
            }

            Message::Close(_reason) => break,

            message => {
                log::warn!("Ignoring other messages {message:?}");
            }
        }
    }

    log::info!("shutting down");
    // attempt to close connection gracefully
    let _ = session.close(None).await;
}

We're running this with a simple cargo run, and connecting to it with:

websocat -v --ping-interval=10 ws://127.0.0.1:8080/ws

The important part here is to close the websocket on the client side with Ctrl+C, and not Ctrl+D (which sends a clean "Close").

In the screen recording below, you can see that actix_http::h1::dispatcher does register something (the closing connection), but the loop on the message_stream.next() doesn't.

We'd expect the shutting down log to appear, but it doesn't.

actix-bug-2025-09-04_10.55.05.mp4

The actorless examples found in https://github.com/actix/examples/tree/master/websockets work around the issue by using an interval (and tokio's select!), but this seems to "hide" the problem rather than solving it, as it forces the reevaluation of message_stream.next(), eventually rendering a None or similar.

[TaeHagen]

Hi,

We run a service that uses a large number of websockets and have run into this issue.

I did some digging, and figured out a few things:
h1_allow_half_closed(false) fixes the issue.

It seems the issue is in stream.rs:

Here, this.closing always gets set to true, however, during disconnect, it appears the function returns Poll::Pending and is never polled again.

Uncommenting that line I added to stop the poll immediately fixes the issue. As does disabling half closed connections.

I traced it to actix-http's h1/dispatcher.rs, and it seems likewise, when and only when h1_allow_half_closed is not false and it exits this way, it ends and is not polled again, despite returning Poll::Pending. When h1_allow_half_closed is set to false, it does seem to always poll one final time to finish it off.

It also seems inconsistent. Even in the buggy setup, occasionally it does close correctly. The majority of the time, however, it does not.

I couldn't find who is responsible for polling the dispatcher. Presumably, whoever is responsible for polling it is stopping (maybe because client disconnected?) and leaving the socket dangling.

I'm pretty frustrated such a serious bug is present in a otherwise production ready server library. For me, or for other consumers, I would just set h1_allow_half_closed. I hope this helps a maintainer or someone who is more familiar with this library than me.