Certain WebSocket unit testing scenarios hang

[vytas7]

It seems that certain WebSocket patterns are tricky to write proper tests for.

For instance, consider an emitter that mostly streams updates to the client:

import asyncio

import falcon.asgi
import falcon.testing


class Channel:
    async def on_websocket(self, req, ws):
        await ws.accept()

        while True:
            await asyncio.sleep(1)
            await ws.send_text('Hello')


@falcon.runs_sync
async def test_ws():
    async with falcon.testing.ASGIConductor(falcon.asgi.App()) as ac:
        ac.app.add_route('/', Channel())
        async with ac.websocket('/') as ws:
            await ws.wait_ready(timeout=3.0)

The above test works just fine.

However, let's say we want to simulate the scenario where no messages are made available for a while (the ws.send_text part is commented out):

import asyncio

import falcon.asgi
import falcon.testing


class Channel:
    async def on_websocket(self, req, ws):
        await ws.accept()

        while True:
            await asyncio.sleep(1)
            # await ws.send_text('Hello')


@falcon.runs_sync
async def test_ws():
    async with falcon.testing.ASGIConductor(falcon.asgi.App()) as ac:
        ac.app.add_route('/', Channel())
        async with ac.websocket('/') as ws:
            await ws.wait_ready(timeout=3.0)

Pytest now hangs forever, the timeout parameter has no effect.

[vytas7]

It seems that the original implementation by @kgriffs was probably working more or less as expected on old versions of CPython (e.g. 3.6) back in the day, however, later we were trying to sprinkle asyncio.sleep(0)s around the code to give these coroutines a chance to run wrt the successive rounds of optimizations and behavioural changes that asyncio underwent in later CPython iterations.

Ideally we ought to refactor the code to do without asyncio.sleep() altoghether, but I haven't explored all ramifications yet.

[vytas7]

We do want to get rid of these sleeps (they cause a couple of tests to fail on GraalPy too, which probably has different behaviour), however, it seems that the particular issue from the description can probably be just documented.

We don't ever cancel the async task, not even after close, and try to await it upon exiting the context manager.