Runtime error if websocket disconnects on a closed connection

[ChronoDK]

First Check

• I added a very descriptive title to this issue.
• I used the GitHub search to find a similar issue and didn't find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google "How to X in FastAPI" and didn't find any information.
• I already read and followed all the tutorial in the docs and didn't find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Example Code

@router.websocket("/websocket")
async def websocket(websocket: WebSocket):
   await websocket.accept()
   try:
      while websocket.client_state == WebSocketState.CONNECTED:
         raw_message = await websocket.receive_bytes()
   except WebSocketDisconnect:
      pass
   finally:
      pass

Description

Connect to the endpoint using any client and make the client die abruptly. The server will fail the closing handshake, as the client is totally gone. It is usually(!) not enough to just close the browser, as it will still have the connection when the server tries to close the websocket. You might have to hit the power switch, or use some client that allows you to instantly kill the connection. I have found a connection made with Godot game engine makes it easy to reproduce, as the engine can be paused for debug and then stopped instantly. As you can imagine, it's not very good, that a client losing power will kill the server.

The error is described in further detail here:
python-websockets/websockets#1072
And seemingly fixed here:
python-websockets/websockets#1086

Which make me think that Fastapi is using an old version of websockets?

Operating System

Linux

Operating System Details

No response

FastAPI Version

0.75.0

Python Version

3,9

Additional Context

No response

[ChronoDK]

Downgrading to websockets==10.1 resolved the issue for me.