support for async factory?

[trim21]

for example:

import aiomysql
import fastapi


async def create_app():
    app = fastapi.FastAPI()

    mysql_pool = await aiomysql.create_pool(autocommit=True, minsize=4, maxsize=20)

    @app.get("/test")
    async def test():
        async with mysql_pool.acquire() as conn:
            async with conn.cursor() as cur:
                await cur.execute(...)

    return app

[Kludex]

Why not use the startup lifespan?

[graingert]

it's not correct to call mysql_pool = await aiomysql.create_pool(...) you should use async with aiomysql.create_pool(...) as mysql_pool:

There's no point providing support for an async factory because there's no way to correctly run background tasks that outlive the factory, or acquire resources that need cleanup. This is what lifespan_context is for

[trim21]

That comes from aiomysql docs: https://github.com/aio-libs/aiomysql?tab=readme-ov-file#basic-example

There's no point providing support for an async factory because there's no way to correctly run background tasks that outlive the factory, or acquire resources that need cleanup. This is what lifespan_context is for

These are not actually true...

For background task you only need asyncio.create_task() and keep a ref for the task in you asgi app. unless somehow uvicorn itself lost track of asgi app instance asgi app get get whold app gc-ed, the ref will never get gc-ed.

There are also resources who have a lifetime almost same as the process, in this example, a database connection pool, so you do not need to cleanup.

[graingert]

This is not correct - you should use a TaskGroup in lifespan, and for resources that have a lifetime the same as the process you will get ResourceWarnings if you don't clean them up explicitly.

Consider also how you'd run your app in tests, you'd leak tasks and resources then too.

[trim21]

I do agree that using lifespan is a good idea, but the other side of lifespan is, it will always result into a global variable or some kind of type erasure. for fastapi per-se, you will end up with a app.state assignment or something else, for starlett you will have to handle a "untyped" state that __getattr__ give you a typing.Any, which you can only find the error at runtime(in test or production) but not at lint time with mypy.

the best solution should be sometime you proposed at #1151

[graingert]

yeah lazgi also looks good