ITADN

`Sink::poll_close` hanging

#128OpenBiagioFesta 创建于 2026-01-12
B
BiagioFestacommented
### Problem `Sink::poll_close` *occasionally* gets stuck [here](https://github.com/Gelbpunkt/tokio-websockets/blob/2db39ce8d333b3040be423564f4958a53bc8ea61/src/proto/stream.rs#L549) returning `Pending` without the *waker* being properly notified when close HS completes, causing clients to hang indefinitely during connection closure. ### Symptoms - Client calls poll_close but never completes - Network trace shows proper WebSocket close handshake: - Client sends `CLOSE` frame ``` UTC TIME 10:59:40.965570801 Client -> Server WebSocket WebSocket Connection Close [FIN] [MASKED] ``` - Server responds with `CLOSE` frame ``` UTC TIME 10:59:40.966434683 Server -> Client WebSocket WebSocket Connection Close [FIN] ``` - Operative System's client process the server `CLOSE`, we see the ACK sent back ``` UTC TIME 10:59:40.966441113 Client -> Server TCP [ACK] (for server CLOSE) ``` - Server closes TCP connection ``` UTC TIME 10:59:40.967625339 Server -> Client TCP [FIN, ACK] ``` - `poll_next_frame` for server's CLOSE frame seems to be never called, thus stream state machine remains stuck despite closed network connection. Adding a debug log, it seems this never complete (expectation returns `None`): https://github.com/Gelbpunkt/tokio-websockets/blob/2db39ce8d333b3040be423564f4958a53bc8ea61/src/proto/stream.rs#L429 At that point the FSM state is `ClosedByUs` (expected because the client initiated the close), states which is waiting the `CLOSE` response. ### Additional Notes This issue occurs intermittently on my hand and is difficult to reproduce systematically. I'll try to collect more data in order to bring more data and help in the identification of the root cause. But lemme know if there are some clues
9 条评论