Aiohttp: El bucle de mensajes de lectura de Websocket genera un error cancelado de bajo nivel cuando la conexión se cierra inesperadamente

Técnicamente, aiohttp crea una tarea por solicitud del cliente.
Al desconectarse el cliente, el sistema detiene la tarea lo antes posible.
La única forma de hacerlo es cancelando la tarea (supongamos que el controlador web está esperando la respuesta de la base de datos u otro servicio, también queremos cancelarlo sin esperar una operación explícita sobre la conexión al cliente websocket).

Task.cancel() se realiza enviando asyncio.CancelledError excepción, la clase de excepción se deriva del estándar Exception . Este es un comportamiento de asyncio, nada específico de aiohttp en sí.

Lo único que podría sugerir es capturar CancelledError en su controlador explícitamente:

try:
    ...
except asyncio.CancelledError:
    pass
except Exception as exc:
    log(exc)

O simplemente no podría captar un tipo tan amplio como Exception .

Veo dos opciones:

• no cambie nada, CancelledError es normal en el mundo asincrónico.
• captura CancelledError y devuelve closed mensaje. Creo que esta es una mejor solución para el controlador webocket.

¿Quizás es mejor introducir una excepción ConnectionClosed separada, de la misma manera que se hizo en la biblioteca websockets ?

Técnicamente, aiohttp crea una tarea por solicitud del cliente.
Al desconectarse el cliente, el sistema detiene la tarea lo antes posible.
La única forma de hacerlo es cancelando la tarea (supongamos que el controlador web está esperando la respuesta de la base de datos u otro servicio, también queremos cancelarlo sin esperar una operación explícita sobre la conexión al cliente websocket).

Creo que este comportamiento me acaba de morder. Tenía un código como este:

async def handler(request):
    ws = web.WebSocketResponse()
    await ws.prepare(request)

    async with contextlib.AsyncExitStack() as stack:
        # acquire_resource_X are async context managers
        await stack.enter_async_context(acquire_resource_1())
        await stack.enter_async_context(acquire_resource_2())
        await stack.enter_async_context(acquire_resource_3())

        async for msg in ws:
            # do stuff

    await ws.close()

    return ws

Después de ponerlo en producción, descubrí que la parte de salida de acquire_resource_3() se omitiría silenciosamente. Más registros revelaron que se estaba recaudando CancelledError dentro de acquire_resource_3 . Esto es lo que creo que sucedió:

• El cliente cierra WebSocket
• async for msg in ws bucle AsyncExitStack comienza a desenrollarse, la parte de salida de acquire_resource_3 comienza a ejecutarse, golpea un await
• aiohttp cancela la tarea del controlador
• CancelledError se recauda dentro de handler en el actual await , que está dentro de acquire_resource_3 , por lo tanto, se omite la parte restante de acquire_resource_3
• La parte de salida de acquire_resource_2 y acquire_resource_1 todavía se ejecuta normalmente, ya que desde su perspectiva simplemente están saliendo de un contexto asíncrono en una excepción

Este es un problema realmente extraño, particularmente porque rompe la expectativa de que la parte saliente de un administrador de contexto siempre se ejecutará. Básicamente, tuve que proteger todos los contextos asíncronos de la cancelación, así:

async def handler(request):
    ws = web.WebSocketResponse()
    await ws.prepare(request)

    await asyncio.shield(asyncio.ensure_future(actually_do_stuff(ws)))

    return ws

async def actually_do_stuff(ws):
    async with contextlib.AsyncExitStack() as stack:
        # acquire_resource_X are async context managers
        await stack.enter_async_context(acquire_resource_1())
        await stack.enter_async_context(acquire_resource_2())
        await stack.enter_async_context(acquire_resource_3())

        async for msg in ws:
            # do stuff

    await ws.close()

¿Hay una mejor manera de hacer esto?