How to manage setup/teardown of resources in async views?

[wgwz]

Is it possible to attach an async resource that requires setup/teardown operations to flask.g? Or are there other ways of dealing with this?

i.e. The aiohttp client requires opening a session in a context manager to make requests, not unlike what you would need to do when interacting with a database.

The flask docs have shown ways of dealing with this for database connections. Is there an idiomatic way to do this with the new async view function support?

Here's a small example that shows a bit of the issue:

@app.post("/")
@ack_reply_or_abort(public_key)
async def slash_command_endpoint():
    cmd = request.json["data"]["name"]
    opts = request.json["data"]["options"]
    result = {}
    async with aiohttp.ClientSession(
        headers=[("User-Agent", "Kyle Lawlor - spacestationbot")],
        raise_for_status=True,
    ) as session:
        if cmd == "weather":
            for opt in opts:
                if opt["name"] == "location":
                    query = opt["value"]
                    result = await fetch_nominatim(session, query, cache=cache)
        lat = result.get("lat")
        lon = result.get("lon")
        if lat and lon:
            weather_report = await fetch_weather(session, lat, lon)
            return {
                "tts": True,
                "type": 4,
                "data": {
                    "embeds": weather_report[:5],
                }
            }
        else:
            return {
                "tts": True,
                "type": 4,
                "data": {
                    "content": "Sorry! There was an issue looking up your location.",
                }
            }

It'd be nice if I could pass the session around to my flask views, similar to how you would for any other flask extension. But I suppose what I might be asking for approaches just having a full async web framework.

Suggestions/discussion appreciated.

[miguelgrinberg]

Hi Kyle!

Interesting problem. I think you should be able to put the aiohttp session in flask.g. I'm writing this from memory, so you'll need to test it, but I think this should work.

First, in a before_request handler you create the session:

@app.before_request
async def before():
    g.session = aiohttp.ClientSession(
        headers=[("User-Agent", "Kyle Lawlor - spacestationbot")],
        raise_for_status=True,
    )

Then in your request you can use g.session to send your request:

# ...
weather_report = await fetch_weather(g.session, lat, lon)
# ...

Finally, an teardown_request handler does the cleanup:

@app.teardown_request
async def teardown(exc):
    await g.session.close()

[wgwz]

It is possible to reproduce this error with a simpler example, just by following the aiohttp quickstart:

index 6278277..ab6be52 100644
--- a/app/main.py
+++ b/app/main.py
@@ -76,6 +76,9 @@ async def slash_command_endpoint():
     logger.debug(f"{request.data=}\n")
     cmd = request.json["data"]["name"]
     opts = request.json["data"]["options"]
+    async with g.session.get('http://httpbin.org/get') as resp:
+        print(resp.status)
+        print(await resp.text())
     result = {}
     if cmd == "weather":
         for opt in opts:

Thanks for you for any help and I apologize if I'm missing something silly.

[miguelgrinberg]

It looks like the event loop used in each handler is different. I thought the same loop was reused in all handlers, but it appears that is not the case, so unfortunately what you want to do does not seem possible with the current implementation.

[miguelgrinberg]

Update: after the realization that this is not going to work with Flask, I tried the same with my aioflask package. This led me to find a small bug in how I was handling the app context, but with that fix everything works. I have created a small example that demonstrates this: https://github.com/miguelgrinberg/aioflask/blob/main/examples/g/app.py.

[davidism]

@pgjones would it be possible to keep the same event loop once one is created during a request?

[nioncode]

@wgwz did you ever find a solution to this? It seems like flask is still running the before/after request and the route handler itself in different event loops, leading to all kinds of subtle issues with our async db connections, which are not cleaned up properly.