Fix: run mcp-server-hello-world in stateless HTTP mode#224
Conversation
The FastMCP app was created with the default stateful HTTP transport, which requires clients to carry an mcp-session-id across requests. Clients that don't (e.g. the Databricks Assistant) get a fresh session on every POST and the server rejects follow-ups with HTTP 400. Pass stateless_http=True so each request is self-contained; this also avoids session-affinity problems on horizontally scaled Databricks Apps. Fixes #141 Co-authored-by: Isaac
|
Integration tests now run and pass with
|
Direct before/after verification of the fixReproduced the exact #141 failure mode locally — a session-less request (what the Databricks Assistant sends, since it doesn't carry an
The 400 is precisely the error reported in #141. With Integration tests still pass ( |
Verified on a live Databricks Apps deployment (e2-dogfood staging)Deployed this branch as a Databricks App and sent session-less requests (no
Same requests against the unfixed stateful build return |
Problem
mcp-server-hello-worldbuilds its FastMCP app with the default stateful HTTP transport (mcp_server.http_app()). Stateful mode requires the client to carry anmcp-session-idheader across requests. The Databricks Assistant does not send that header, so every POST creates a new session and the server rejects the follow-up request with HTTP 400 — even though the same server works fine in the Playground (which does maintain the session). See #141 for the reporter's trace.Change
Stateless mode makes each request self-contained, so clients that don't track a session id work. It also avoids session-affinity issues on horizontally scaled Databricks Apps where consecutive requests can land on different replicas. The server's tools (
health,get_current_user) hold no per-session state, so there's no functional downside.Fixes #141