Repository navigation
Deploy docs: reused-process runtimes (Lambda) hit the single-use session manager error, but aren't covered #3590
Description
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.
Activity
Ben-Home commentedon Sep 28, 2026
Your fix (build the app inside the handler, per invocation) is the correct workaround today, and the deeper design question for the maintainers is whether the session manager lifespan should be re-enterable so long-lived, reused-process deployments can build once at import and serve many invocations. The current single-use manager forces per-invocation construction, which re-pays app setup and lifespan startup on every warm invocation, and on serverless platforms that cost shows up as latency plus the occasional cold-start surprise.
Two suggestions:
We run MCP servers in reused-process environments too at CorpusIQ (corpusiq.io), and the rule we landed on is the same one you found: treat lifespan-managed state as per-invocation unless the SDK explicitly documents reuse.