Q: will Mangum run lifespan multiple times?

[dimaqq]

I'm trying to run fastapi app with custom lifespan-aware middleware.
It works fine under uvicorn, but fails oddly under mangum.

The error is:

File "my-middleware-that-tries-to-honour-lifespan.py", line 98, in __call__
 await self.under.__aenter__()
File "/usr/local/lib/python3.10/contextlib.py", line 197, in __aenter__
 del self.args, self.kwds, self.func
AttributeError: args

(That's Py 3.10 error, the exception is a bit misleading: https://bugs.python.org/issue45996)

The cause is that my middleware accepts an instance of an asynccontextmanager, and it runs __aenter__ on lifespan.startup
and __aexit__ on lifespan.shutdown.

In the FastAPI/starlette/uvicorn combo, there's a case (maybe even an assumption) that startup and shutdown are ran only once. After that the entire app is thrown away.

However, it seems, as if mangum runs lifespan.startup multiple times.
Perhaps that's how it deals with lambda being suspended?

[jordaneremieff]

The startup and shutdown events are only expected to run once.

How are you running Mangum using 3.10? It currently only supports the latest Python version that AWS Lambda supports (3.9).

I’ll move this to discussions because it doesn’t seem like a bug specifically in Mangum at this point.

[evanandrews-xrd]

I believe I've also run into this.

For every request, mangum runs the startup event, then the handler, then the shutdown event. For applications with expensive startup tasks, this is wasteful and does not match my understanding of ASGI lifespan semantics.

Consider the following FastAPI application:

import asyncio
from fastapi import FastAPI
from mangum import Mangum

app = FastAPI()


@app.on_event("startup")
async def on_startup():
    print("> Starting up")
    await asyncio.sleep(3)  # Simulate expensive startup tasks


@app.get("/")
async def read_root():
    print("> Handling request")
    return "Hello World!"


@app.on_event("shutdown")
async def on_shutdown():
    print("> Shutting down")


handler = Mangum(app)

When run via Uvicorn it behaves as expected. on_startup is run once at startup, read_root is run once per request, and on_shutdown is run when the server terminates.

$ python -m uvicorn main:app
INFO:     Started server process [5540]
INFO:     Waiting for application startup.
> Starting up
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
> Handling request
INFO:     127.0.0.1:49176 - "GET / HTTP/1.1" 200 OK
> Handling request
INFO:     127.0.0.1:49176 - "GET / HTTP/1.1" 200 OK
INFO:     Shutting down
INFO:     Waiting for application shutdown.
> Shutting down
INFO:     Application shutdown complete.
INFO:     Finished server process [5540]

The server takes some time to start up, but responds promptly to individual requests.

However, when run using Mangum with Lambda and API Gateway, this is not the case.

The Lambda must be configured with a longer timeout as the 3 seconds at startup is counted against the request rather than as Init time.

START RequestId: [1] Version: $LATEST
> Starting up
> Handling request
> Shutting down
END RequestId: [1]
REPORT RequestId: [1]	Duration: 3411.76 ms	Billed Duration: 3412 ms	Memory Size: 128 MB	Max Memory Used: 56 MB	Init Duration: 492.79 ms	
START RequestId: [2] Version: $LATEST
> Starting up
> Handling request
> Shutting down
END RequestId: [2]
REPORT RequestId: [2]	Duration: 3006.11 ms	Billed Duration: 3007 ms	Memory Size: 128 MB	Max Memory Used: 56 MB	

Notice the first request has an Init Duration of 492.79 ms to load the runtime. The 3000ms on_startup time is included in the duration of every request. The second request does not have an Init Duration as the Lambda environment has reused the process (see https://docs.aws.amazon.com/lambda/latest/dg/runtimes-context.html).

Unfortunately it seems like the only way to implement this correctly is to register an extension (https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html) in order to receive and process the shutdown event.
This seems non-trivial and is beyond my AWS knowledge.

My current workaround is to disable Mangum's lifespan handling and run my start function manually:

handler = Mangum(app, lifespan="off")


if "AWS_EXECUTION_ENV" in os.environ:
    loop = asyncio.get_event_loop()
    loop.run_until_complete(app.router.startup())

This is sufficient for my use case because I do not require any shutdown logic.

[joshorr]

I am having the same trouble as evanandrews-xrd. In my case I am using SentryAsgiMiddleware from sentry, and it slows my lambda a lot more then it should due to the shutdown event happening on every lambda invocation/request.

I'm going to try out his solution.

[vincentsarago]

lifespan will be run on each invocation

from mangum import Mangum
from fastapi import FastAPI
from starlette.requests import Request


app = FastAPI()
app.state.start_count = 0
app.state.off_count = 0

@app.get("/check")
def landing(request: Request):
    return {
        "start": request.app.state.start_count,
        "end": request.app.state.off_count,
    }


@app.on_event("startup")
async def startup_event():
    """Connect to database on startup."""
    print("Startup")
    app.state.start_count += 1


@app.on_event("shutdown")
async def shutdown_event() -> None:
    """Close database connection."""
    print("Shutdown")
    app.state.off_count += 1


handler = Mangum(app, lifespan="auto")

$ curl {endpoint}/check | jq
{
  "start": 1,
  "end": 0
}

$ curl {endpoint}/check | jq
{
  "start": 2,
  "end": 1
}

$ curl {endpoint}/check | jq
{
  "start": 3,
  "end": 2
}

Solution provided by @evanandrews-xrd works and it also seems to be that lambda-extension is the only proper solution :-(

[kingcdavid]

Hi All

Also seeing this issue, Should this not be considered a bug? as lifespan should be for the lifetime of the application, not for a request

Thanks