ConnectionClosed exception from serve_websocket() #96
Comments
|
From the trace, it's clearly related to a newly incoming connection. There is probably server code using This is a trio-websocket reliability issue for my use case, happening enough to be a problem. (Note that async stack traces can mislead by incorrectly attributing code location to the last line of an async block. E.g. the exception in |
|
I'll look at it this week. |
|
I think I've managed to reproduce this. Here is an implementation of a faulty server: from random import random
import trio
from trio_websocket import serve_websocket, ConnectionClosed
async def main():
''' Main entry point. '''
print('Starting websocket server…')
await serve_websocket(handler, 'localhost', 8000, ssl_context=None)
async def handler(request):
''' Reverse incoming websocket messages and send them back. '''
try:
ws = await request.accept()
await ws.send_message('foo')
await trio.sleep(random()/1000)
await trio.aclose_forcefully(ws._stream)
except ConnectionClosed:
pass
if __name__ == '__main__':
trio.run(main)The client is this: import trio
from trio_websocket import connect_websocket, ConnectionClosed
async def main():
async with trio.open_nursery() as nursery:
for n in range(1000):
print('connection {}'.format(n))
try:
connection = await connect_websocket(nursery, 'localhost', 8000,
'/', use_ssl=False)
await connection.get_message()
await connection.aclose()
except ConnectionClosed:
print('connection closed')
if __name__ == '__main__':
trio.run(main)The client connects to the server repeatedly. Within a small number of iterations (often less than 10), the server crashes with the following exception. The root cause is that the reader task is getting a connection closed event, and it wants to call Keeping mind that I want to overhaul the close logic in #90 at a later date, I'll try to keep the fix for this bug as small as possible. The simplest fix is that the reader task should catch With these changes, the scripts above run without error. I'll work on a test case tomorrow. The bug is triggered by a race (it only occurs if the server has a random delay added), so building a test case should be a matter of carefully sequencing events. |
|
Thank you! That does seem to match, and my app has a non-trivial amount of stuff on the trio scheduler which could cause the delay. |
Hit a case where serve_websocket is leaking a ConnectionClosed exception. My handler doesn't appear to be involved in this trace. What am I missing?
The text was updated successfully, but these errors were encountered: