Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

when receive() raise ConnectionClosed, it ignores contents in input_buffer #30

Closed
xiaosong-ai opened this issue Sep 22, 2023 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@xiaosong-ai
Copy link

raise ConnectionClosed(self.close_reason, self.close_message)

Can we release input_buffer contents to receiver before raise ConnectionClosed? The code should looks like this:

def receive(self, timeout=None):
    """Receive data over the WebSocket connection.

    :param timeout: Amount of time to wait for the data, in seconds. Set
                    to ``None`` (the default) to wait indefinitely. Set
                    to 0 to read without blocking.

    The data received is returned, as ``bytes`` or ``str``, depending on
    the type of the incoming message.
    """
    while self.connected and not self.input_buffer:
        if not self.event.wait(timeout=timeout):
            return None
        self.event.clear()
    if not self.connected:  # pragma: no cover
  •        if not self.input_buffer.empty():
    
  •           return self.input_buffer.pop(0)
          raise ConnectionClosed(self.close_reason, self.close_message)
      return self.input_buffer.pop(0)
    
@xiaosong-ai
Copy link
Author

the added code should be:

if not self.input_buffer:
    return self.input_buffer.pop(0)

@miguelgrinberg
Copy link
Owner

Yes, I think this is a reasonable change. I'll look into it.

@miguelgrinberg miguelgrinberg self-assigned this Sep 22, 2023
@miguelgrinberg miguelgrinberg added the bug Something isn't working label Sep 22, 2023
@sanchay-hai
Copy link

Thanks @miguelgrinberg. We can test both #29 and #30 at the same time.

@sanchay-hai
Copy link

Hey @miguelgrinberg we've been using 6c87abe22215c45b3dc0dadc168c3dd061eb2aa4 successfully for the past few days

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants