Running our MCP server (Streamable HTTP) on AWS Lambda, every second invocation against a warm container failed outright, on every request, with:
RuntimeError: StreamableHTTPSessionManager .run() can only be called once per instance. Create a new instance if you need to run again.
It happens the first time any Lambda container gets reused, which is the normal, expected behavior in production. Not an edge case. Discovered it testing against real repeated traffic, not a single request. Anyone deploying a Streamable HTTP MCP server to Lambda the natural way (build the app once, at import time, like you would for any long-running server) hits this the moment a container is reused.
Root cause: the app was built once at import time, so its session manager's lifespan ran and finished during the first invocation. The second invocation reuses the same process and tries to enter that same manager's lifespan again, which it refuses.
docs/troubleshooting.md already documents this exact error for two other causes (a Mount swallowing a lifespan, several long-running workers). Neither matches a serverless/reused-process deployment, and nothing pointed us at the actual fix. Had to reproduce the crash directly to find the fix.
Fix: build the app fresh inside the handler, per invocation, instead of at module scope.
Running our MCP server (Streamable HTTP) on AWS Lambda, every second invocation against a warm container failed outright, on every request, with:
It happens the first time any Lambda container gets reused, which is the normal, expected behavior in production. Not an edge case. Discovered it testing against real repeated traffic, not a single request. Anyone deploying a Streamable HTTP MCP server to Lambda the natural way (build the app once, at import time, like you would for any long-running server) hits this the moment a container is reused.
Root cause: the app was built once at import time, so its session manager's lifespan ran and finished during the first invocation. The second invocation reuses the same process and tries to enter that same manager's lifespan again, which it refuses.
docs/troubleshooting.mdalready documents this exact error for two other causes (aMountswallowing a lifespan, several long-running workers). Neither matches a serverless/reused-process deployment, and nothing pointed us at the actual fix. Had to reproduce the crash directly to find the fix.Fix: build the app fresh inside the handler, per invocation, instead of at module scope.