websocket-client: Release 1.0.0 caused an AttributeError: 'NoneType' object has no attribute 'settimeout' on websocketapp.close()

Hi,

With the 1.0.0 release, a major update in WebSocket.close() function in _core.py was done and it causes an AttributeError when we try to close WebSocketApp.

This issue is a side effect of an update in websocket-client/_core.py file

Initially, the code of WebSocket.close() function was:

    def close(self, status=STATUS_NORMAL, reason=six.b(""), timeout=3):
            ....
            try:
                ....
                self.sock.settimeout(sock_timeout)
                self.sock.shutdown(socket.SHUT_RDWR)
            except:
                pass

Now, exceptions are no more catched … except for Mac OS (!?!) :

    def close(self, status=STATUS_NORMAL, reason=bytes('', encoding='utf-8'), timeout=3):
            ....
            try:
                ....
                self.sock.settimeout(sock_timeout)
                self.sock.shutdown(socket.SHUT_RDWR)
           except OSError:  # This happens often on Mac
                pass
            except:
                raise

I found one reason that could cause self.sock set to None : when frame is decoded (line 479: frame = self.recv_frame()), if there is any error during decoding, the web socket is closed and set to None:

    def _recv(self, bufsize):
        try:
            return recv(self.sock, bufsize)
        except WebSocketConnectionClosedException:
            if self.sock:
                self.sock.close()
            self.sock = None
            self.connected = False
            raise

I suppose our issue isn’t new but was hidden by the try / except pass until 1.0.0 release.

Could you test self.sock before trying to set timeout and call shutdown() ?

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 1
  • Comments: 16

Commits related to this issue

Most upvoted comments

@eirikur-grid thanks, I can recreate the issue now using a virtual env, even with the latest python-socketio v5.3.0. Unfortunately it’s unclear to me at first glance whether the issue is in websocket-client or elsewhere. I might not have time to dig into this much deeper in the next 24 hours or so, but I will provide updates if I find something. Maybe other websocket-client users can provide more insight if the issue is widespread.

@miguelgrinberg since you’re the author of python-engineio and python-socketio, do you have insight to whether the issue in this thread might be due to websocket-client or the engineio/socketio code? The v1.0.0 release of websocket-client (released about 12 hours ago) may have impacted socket-io/engine-io functionality, so if your unit tests reveal a problem in websocket-client, I can look into it.

@miguelgrinberg thank you for your insights, I agree that the issue stems from one of a recent change in websocket-client. If any issues appear in your projects like this, you can direct them here. I hope to have this resolved soon.