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

Resolve "Default max_queue blocks websocket cancellation with high traffic" #1556

Conversation

btschwertfeger
Copy link

@btschwertfeger btschwertfeger commented Nov 27, 2024

Problem statement

If max_queue is not set to None and the connection closes while receiving a high volume of messages, it can trigger websockets.asyncio.client.messages.py:Assembler.paused == True. This results in self.pause() blocking termination, as frames are still pending processing. This issue arises only when the connection handles a significant influx of messages between the initiation of cancellation and its final acknowledgment.

Solution proposal

In order to avoid this behavior, we introduce Assembler.prepare_close() to continue any paused processing while setting Assembler.closing=True allows skipping further calls of Assembler.maybe_pause().

  # src.websockets.asyncio.connection.py:915... (see MR diff)
  async with asyncio_timeout_at(self.close_deadline):
+     self.recv_messages.prepare_close()
      await asyncio.shield(self.connection_lost_waiter)

Tasks:

  • add proper MR description and reasoning behind the change
  • add/update documentation (not needed I guess)
  • test the change properly
  • remove repro file (after first review)

Closes #1555

Sorry, something went wrong.

Verified

This commit was signed with the committer’s verified signature.
btschwertfeger Benjamin T. Schwertfeger
…traffic"

Verified

This commit was signed with the committer’s verified signature.
btschwertfeger Benjamin T. Schwertfeger
@btschwertfeger btschwertfeger force-pushed the 1555-default-max-queue-blocks-ws-cancellation branch from 15c940b to d51831c Compare November 28, 2024 16:34

Verified

This commit was signed with the committer’s verified signature.
btschwertfeger Benjamin T. Schwertfeger
@btschwertfeger btschwertfeger force-pushed the 1555-default-max-queue-blocks-ws-cancellation branch from d51831c to f4d0b20 Compare November 28, 2024 16:51

Verified

This commit was signed with the committer’s verified signature.
btschwertfeger Benjamin T. Schwertfeger
@btschwertfeger btschwertfeger force-pushed the 1555-default-max-queue-blocks-ws-cancellation branch from 6b64efd to c4b3d2b Compare November 28, 2024 17:11
@btschwertfeger btschwertfeger marked this pull request as ready for review November 28, 2024 17:12
@aaugustin
Copy link
Member

Closing the loop here after I merged a different fix in 613f3f0 — resuming reading is the wrong approach because it could lead to bypassing security limits; the correct approach is to close the socket and drop the buffer. Interestingly there's more code removed than added in the fix.

@aaugustin aaugustin closed this Jan 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Default max_queue blocks websocket cancellation with high traffic
2 participants