Replies: 2 comments
-
Based on the linked issue, as tiangelo pointed out the response is not handled at the application level (ie. in your FastAPI code). In this case you do nothing. Uvicorn (or whatever asgi server) is responsible for returning the pong message. |
Beta Was this translation helpful? Give feedback.
-
Oops lost track of this issue. Ty for the response. I think I was under the false impression that my server wasn't discovering disconnections from clients responsively and needed to send a ping out or write random text to the socket in order to cause the connection to be cleaned up. It turns out that if everything is working right, FastAPI should automatically close the stale connections up without needing any explicit socket writes as a work around. I believe in my case (my implementation has changed quite a bit since posting this), I was having problems because I had threads that were holding the around after FastAPI had. It's curious that there aren't any other mentions to #7940 that raise this point. |
Beta Was this translation helpful? Give feedback.
-
Privileged issue
Issue Content
I just read #626, and it seems like handling ping was discussed and resolved, but nothing was mentioned around sending a ping out to a client. I believe that would test the connection and allow a WebsocketDiscconnect exception to be thrown allowing the connection to be cleaned up. It seems though that the websocket I'm referencing doesn't expose a
.conn
attribute so I don't understand how to send a ping. Could someone provide a more explicit explanation around invoking websocket ping from the server to validate connections?Beta Was this translation helpful? Give feedback.
All reactions