Aiohttp: Websocket-Lese-Nachrichtenschleife löst CanceledError auf niedriger Ebene aus, wenn die Verbindung unerwartet geschlossen wird

Technisch erstellt aiohttp eine Aufgabe pro Client-Anfrage.
Beim Trennen des Clients stoppt das System die Task so schnell wie möglich.
Die einzige Möglichkeit, dies zu tun, ist das Abbrechen der Aufgabe (angenommen, der Web-Handler wartet auf eine Antwort von der DB oder einem anderen Dienst, wir möchten ihn auch abbrechen, ohne auf eine explizite Operation über die Verbindung zum Websocket-Client zu warten).

Task.cancel() wird durch das Senden von asyncio.CancelledError Ausnahme ausgeführt, die Ausnahmeklasse wird vom Standard Exception . Dies ist ein asyncio-Verhalten, nichts Spezifisches für aiohttp selbst.

Das einzige, was ich vorschlagen könnte, ist, CancelledError explizit in Ihrem Handler zu fangen:

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

Oder Sie könnten einfach nicht so breite Texte wie Exception .

Ich sehe zwei Möglichkeiten:

• nichts ändern, CancelledError ist in der asynchronen Welt normal.
• CancelledError abfangen und closed Nachricht zurückgeben. Ich denke, dies ist die bessere Lösung für Webocket-Handler.

Vielleicht ist es besser, eine separate ConnectionClosed-Ausnahme einzuführen, genau wie in der Websockets- Bibliothek?

Technisch erstellt aiohttp eine Aufgabe pro Client-Anfrage.
Beim Trennen des Clients stoppt das System die Task so schnell wie möglich.
Die einzige Möglichkeit, dies zu tun, ist das Abbrechen der Aufgabe (angenommen, der Web-Handler wartet auf eine Antwort von der DB oder einem anderen Dienst, wir möchten ihn auch abbrechen, ohne auf eine explizite Operation über die Verbindung zum Websocket-Client zu warten).

Ich glaube, ich wurde gerade von diesem Verhalten gebissen. Ich hatte einen Code wie diesen:

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

Nachdem ich es in Produktion genommen hatte, stellte ich fest, dass der aufregende Teil von acquire_resource_3() stillschweigend übersprungen würde. Weitere Protokollierung ergab, dass ein CancelledError innerhalb von acquire_resource_3 . Folgendes ist meiner Meinung nach passiert:

• Client schließt den WebSocket
• async for msg in ws Schleife wird beendet, AsyncExitStack beginnt sich abzuwickeln, der Ausgangsteil von acquire_resource_3 beginnt mit der Ausführung, trifft auf await
• aiohttp bricht die Handler-Aufgabe ab
• CancelledError wird innerhalb von handler zum aktuellen await erhöht, der innerhalb von acquire_resource_3 , daher wird der verbleibende Teil von acquire_resource_3 übersprungen
• Der beendende Teil von acquire_resource_2 und acquire_resource_1 immer noch normal ausgeführt, da sie aus ihrer Sicht einfach einen asynchronen Kontext bei einer Ausnahme verlassen

Dies ist ein wirklich seltsames Problem, insbesondere weil es die Erwartung bricht, dass der Exit-Teil eines Kontextmanagers immer ausgeführt wird. Ich musste im Grunde alle asynchronen Kontexte wie folgt vor dem Abbruch schützen:

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

Gibt es einen besseren Weg, dies zu tun?