Skip to content

Add loop_factory parameter for persistent event loops#363

Open
jrobbins-LiveData wants to merge 6 commits intoKludex:mainfrom
jrobbins-LiveData:add-loop-factory
Open

Add loop_factory parameter for persistent event loops#363
jrobbins-LiveData wants to merge 6 commits intoKludex:mainfrom
jrobbins-LiveData:add-loop-factory

Conversation

@jrobbins-LiveData
Copy link

Summary

Adds an optional loop_factory parameter to Mangum that enables persistent event loops across Lambda invocations. This is similar to uvicorn's loop parameter.

Use cases:

  • Reusing async resources (database connections, HTTP clients) across warm invocations
  • Using alternative event loop implementations like uvloop for better performance
  • Managing the event loop externally for advanced lifecycle control

Changes

  • Added loop_factory: LoopFactory | None parameter to Mangum.__init__
  • When provided, the factory is called once at initialization and the loop is reused for all invocations
  • Added LoopFactory type alias to mangum.types for external use
  • Added documentation section "Persistent event loop" to docs/adapter.md
  • Added 4 tests covering the new functionality

Usage

import asyncio
from mangum import Mangum

handler = Mangum(app, lifespan="off", loop_factory=asyncio.new_event_loop)

Or with uvloop:

import uvloop
from mangum import Mangum

handler = Mangum(app, lifespan="off", loop_factory=uvloop.new_event_loop)

Notes

The loop is not closed automatically by Mangum - in Lambda, it persists until the execution environment is recycled
For testing, callers are responsible for closing the loop explicitly

Related

Addresses use case discussed in #361

jrobbins-LiveData and others added 6 commits January 9, 2026 17:08
This is a local settings file that shouldn't be tracked.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Remove mangum-ld package rename and CodeArtifact config that were
used for testing. Restore original package name and version.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The event loop only needs to be set as current once when created,
not on every request invocation.

Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
@Kludex
Copy link
Owner

Kludex commented Jan 14, 2026

asyncio_run receives loop_factory already, the idea was to pass that, wasn't it?

@jrobbins-LiveData
Copy link
Author

AFAICT, passing loop_factory to asyncio_run() would still create and close a new loop per Lambda invocation, which would defeat the intent to keep the same event loop instance alive across Lambda invocations so that async resources (database connection pools, HTTP client sessions, etc) persist in warm containers. The run_until_complete() approach reuses the same loop instance.

@tampueroc
Copy link

Hi @jrobbins-LiveData. Is the issue still persisting after #375?

@jrobbins-LiveData
Copy link
Author

@tampueroc, the revert to previous loop behavior in #376 fixed the issue that #375 had caused us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants