Resolve "Default max_queue
blocks websocket cancellation with high traffic"
#1556
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem statement
If
max_queue
is not set toNone
and the connection closes while receiving a high volume of messages, it can triggerwebsockets.asyncio.client.messages.py:Assembler.paused == True
. This results inself.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 settingAssembler.closing=True
allows skipping further calls ofAssembler.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:
Closes #1555