0.20.0 is a breaking change

[jrobbins-LiveData]

The previous version allowed us to create our own asyncio event loop because it used asyncio.get_event_loop(). The new version (0.20.0), in newer versions of Python, uses asyncio.run() which creates its own event loop, and destroys the loop when done.

Not only does this change break our Mangum use-cases, it also means that you cannot keep the event loop across Lambda warm invokes. Which means that you can no longer follow "best practice" and retain, e.g. a global httpx AsyncClient for reuse, because httpx binds its AsyncClient to the current event loop. AWS recommends this kind of retention as an efficiency measure. It would be a shame if asyncio/ASGI-oriented apps could no longer follow this best practice and be forced to recreate such resources on every Lambda invoke.

It would be helpful if we had the option to pass in an event_loop factory so that we could retain the useful behavior of not treating each warm Lambda invoke as a completely new context. By making this an opt-in feature, people could have the simplicity of letting Mangum take care of spinning up the asyncio event loop (on every Lambda event) without precluding more advanced use-cases.

Is this idea of an "event loop factory" acceptable as a possible PR? Or is there another approach here that would let us continue to enjoy the old behavior?

[jmehnle]

It turns out these changes had another unfortunate side-effect. We're running a FastAPI-based API on AWS Lambda with Python 3.12, Mangum, AnyIO(!), and SQLAlchemy/asyncpg against a PostgreSQL database, and since the Mangum 0.20 release we've observed a database connection leak with every incoming request. In our case we serve a variety of requests, but even during periods of quiet we still have one incoming request every 5 minutes. This is the number of open DB connections from PostgreSQL/RDS's point of view:

Every little step on these ~25-step staircases is 5 minutes deep. I don't fully understand yet why the staircases are only 25 steps tall, but the underlying issue is clear: database connections are not closed properly. This effect goes away if I downgrade Mangum to 0.19.

Unlike @jrobbins-LiveData we use AnyIO, not asyncio directly, and we don't explicitly do anything to preserve the event loop across Lambda requests. We do, however, use the following to cache SQLAlchemy engines for the life time of the event loop:

from anyio.lowlevel import RunVar

# `AsyncEngine` uses futures bound to an async event loop and hence must not be reused
# across loops. `RunVar` implicitly prevents this.
_sqlalchemy_engine: RunVar[AsyncEngine] = RunVar('_sqlalchemy_engine')

async def get_sqlalchemy_engine() -> AsyncEngine:
    try:
        return _sqlalchemy_engine.get()
    except LookupError:
        engine = create_async_engine(
            f'postgresql+asyncpg://...',
            pool_pre_ping=True,
        )
        _sqlalchemy_engine.set(engine)
        return engine

What do we need to understand about 0.20's changed interface/protocol to prevent this from happening?

[jrobbins-LiveData]

Proposal: optional event loop reuse strategy for AWS Lambda

Mangum 0.20.0 switched to using asyncio.run() (and asyncio.Runner on Python 3.11), which forces a new event loop for every invocation and closes it immediately afterward. As a result, event loop reuse across warm AWS Lambda invocations is no longer possible without patching internals.

Looking at the current implementation (mangum/_compat.py and mangum/adapter.py), every invocation ultimately does:

return asyncio_run(handle_request())

On Python ≥3.11 this always results in the event loop being shut down at the end of the call, either via asyncio.run() or by exiting a Runner context manager.

Why this matters in Lambda:

AWS Lambda reuses the execution environment between warm invocations. Reusing a single event loop can be desirable or necessary in cases such as:

• async database connections or connection pools that are bound to a specific event loop

• async HTTP clients (e.g. httpx.AsyncClient) that are intended to be reused across requests

• avoiding “attached to a different event loop” errors on warm starts

• maintaining compatibility with existing Lambda workloads that relied on loop reuse prior to 0.20.0

Suggested approach: loop_strategy

Introduce an optional configuration parameter to control how the event loop is managed:

Mangum(app, loop_strategy="run")      # default (current behavior)
Mangum(app, loop_strategy="runner")   # reuse event loop across warm invocations

An environment variable override (e.g. MANGUM_LOOP_STRATEGY=runner) could also be supported. It could be added later if maintainers think it’s useful, and it’s not required for the core idea.

loop_strategy="run" (default)

• Current 0.20.0 behavior

• A new event loop is created per invocation

• The loop is closed immediately after the request completes

loop_strategy="runner" (Python 3.11+)

• Create a single asyncio.Runner once per execution environment

• Reuse it for subsequent invocations

• Do not use the Runner as a context manager, so the loop is not closed

• All warm invocations share the same event loop

This allows multiple .run() calls on the same Runner while preserving explicit control over the loop lifecycle.

---

Notes

This would be explicitly opt-in behavior. Users enabling it would be responsible for ensuring that background tasks or loop-bound state do not leak unintentionally across invocations.

The default behavior would remain unchanged.

[Kludex]

I'm open to accept a loop_factory parameter, as uvicorn does now.

[jmehnle]

@Kludex, would you be willing to point out what I'm missing with regard to our use of Mangum 0.20 that might cause a DB connection to be leaked on each request? I'm happy to debug this further, but I honestly don't understand the semantic change that came with 0.20, and I don't see it documented anywhere.

[mlorenc-sonnen]

This change appears to break asyncpg connection pooling between warm lambda invokes, forcing to use no pool or RDS proxy. It would be great to have a choice to continue reusing the event loop between warm invocations.

[jrobbins-LiveData]

@Kludex I created #363 to try to address this issue on an opt-in basis.

[matpag]

I can confirm jrobbins issues because we have the same problem with a Mangum and FastAPI application when moved to 0.20.0

We had to rollback to 0.19.0

[Kludex]

My previous comment doesn't seem to make sense. I think we should revert and properly support 3.14. I'll do that now. I'm sorry for the delay.

[Kludex]

I've merged #375 instead.

---

@jmehnle We don't really need the loop_factory parameter, if people are using uvloop or alternatives, they can do:

import uvloop
import asyncio

loop = uvloop.new_event_loop()
asyncio.set_event_loop(loop)

# then mangum...

Do you still think we should have the parameter?

---

Sorry the confusion - I think by default this package should warm start.