Aiohttp: O loop da mensagem de leitura do Websocket aumenta CanceledError de baixo nível quando a conexão é fechada inesperadamente

Tecnicamente, aiohttp cria uma tarefa por solicitação do cliente.
Na desconexão do cliente, o sistema interrompe a tarefa o mais rápido possível.
A única maneira de fazer isso é cancelando a tarefa (vamos supor que o manipulador da web esteja aguardando a resposta do banco de dados ou outro serviço, queremos cancelá-lo também sem esperar por uma operação explícita na conexão com o cliente do websocket).

Task.cancel() é feito enviando asyncio.CancelledError exception, a classe de exceção é derivada do padrão Exception . Este é um comportamento assíncio, nada específico para o próprio aiohttp.

A única coisa que eu poderia sugerir é capturar CancelledError em seu manipulador explicitamente:

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

Ou você pode simplesmente não pegar um tipo tão amplo como Exception .

Vejo duas opções:

• não mude nada, CancelledError é normal no mundo assíncrono.
• pegar CancelledError e retornar closed mensagem. Eu acho que essa é a melhor solução para o manipulador de webocket.

Talvez seja melhor introduzir uma exceção ConnectionClosed separada, da mesma forma que foi feito na biblioteca de websockets ?

Tecnicamente, aiohttp cria uma tarefa por solicitação do cliente.
Na desconexão do cliente, o sistema interrompe a tarefa o mais rápido possível.
A única maneira de fazer isso é cancelando a tarefa (vamos supor que o manipulador da web esteja aguardando a resposta do banco de dados ou outro serviço, queremos cancelá-lo também sem esperar por uma operação explícita na conexão com o cliente do websocket).

Acho que acabei de ser mordido por esse comportamento. Eu tinha um 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

Depois de colocá-lo em produção, descobri que a parte final de acquire_resource_3() seria ignorada silenciosamente. Mais registros revelaram que CancelledError estava sendo gerado dentro de acquire_resource_3 . Aqui está o que acho que aconteceu:

• O cliente fecha o WebSocket
• async for msg in ws loop sai, o AsyncExitStack começa a se desenrolar, a parte de saída de acquire_resource_3 começa a executar, atinge um await
• aiohttp cancela a tarefa do manipulador
• CancelledError é gerado dentro de handler no atual await , que está dentro de acquire_resource_3 , portanto, a parte restante de acquire_resource_3 é ignorada
• A parte de saída de acquire_resource_2 e acquire_resource_1 ainda é executada normalmente, pois da perspectiva deles eles estão simplesmente saindo de um contexto assíncrono em uma exceção

Este é um problema realmente estranho, principalmente porque quebra a expectativa de que a parte existente de um gerenciador de contexto sempre será executada. Tive que basicamente proteger todos os contextos assíncronos do cancelamento, como este:

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()

Existe uma maneira melhor de fazer isso?