Disconnecting from sid room yields unexpected disconnecting behavior

[burchill]

Describe the bug
In the process of learning how Flask-SocketIO works, I was playing around with the example provided in example/app.py. I noticed that if you close the sid room you are in, when you then issue the disconnect_request command, nothing happens, and you continue to stay connected (although refreshing the page seems to then properly disconnect you).

I changed the disconnect_request function to just call disconnect(), and in this case, it works correctly, suggesting it's something to do with the callback function implementation. To be honest, I'm not entirely sure if this is unexpected behavior or not, but I can't find anything in the JS code in index.html to suggest that disconnected from the sid room would screw things up.

To Reproduce
I'm using Python 3.4 with the default Werkzeug server with the eventlet async mode on OSX 10.12 with Chrome 81.
Steps to reproduce the behavior:

1. Run app.py in the example folder with , logger=True, engineio_logger=True in the SocketIO options.
2. Open the page in the browser.
3. Copy-and-paste the sid into the 'Close Room' input, and press it.
4. Press 'Disconnect'
5. Watch as you continue to receive server-generated events.

Expected behavior
I would have assumed that disconnect_request would work even if you have left your original sid room.

Logs

ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["close_room",{"room":"ff61c5f0d2b24cb3924a7fcf7614a249"}]
received event "close_room" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_response" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Sending packet MESSAGE data 2/test,["my_response",{"count":2,"data":"Room ff61c5f0d2b24cb3924a7fcf7614a249 is closing."}]
room ff61c5f0d2b24cb3924a7fcf7614a249 is closing [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["my_ping"]
received event "my_ping" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_pong" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["disconnect_request"]
received event "disconnect_request" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_response" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["my_ping"]
received event "my_ping" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_pong" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["my_ping"]
received event "my_ping" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_pong" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["my_ping"]
received event "my_ping" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_pong" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Received packet MESSAGE data 2/test,["my_ping"]
received event "my_ping" from ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_pong" to ff61c5f0d2b24cb3924a7fcf7614a249 [/test]
emitting event "my_response" to all [/test]
ff61c5f0d2b24cb3924a7fcf7614a249: Sending packet MESSAGE data 2/test,["my_response",{"count":1,"data":"Server generated event"}]

It then continues as normal, continuing to ping the client and send regular 'Server generated event[s]. I included so many lines after the disconnect_requestbecause theemitting event "my_response" to all [/test]` log only seems to happen when there are no clients connected, and after that one instance, never happens again.

[miguelgrinberg]

What would be the purpose of closing a sid room?

The code unfortunately does not currently validate against this, but the sid rooms are not meant to be touched, they are just there to facilitate addressing individual clients. Need to add validation to ignore such requests.

[burchill]

I can't think of a reason why anyone would, other than to mess something up. Moving forward, I'll just hide the user's sid from them when displaying their current rooms.