Fix: run mcp-server-hello-world in stateless HTTP mode#224
Open
noramxiao wants to merge 1 commit into
Open
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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.Testing
Integration tests pass with
stateless_http=True:Direct before/after verification of the fix
Reproduced the exact #141 failure mode locally — a session-less request (what the Databricks Assistant sends, since it doesn't carry an
mcp-session-idheader):http_app(), before fix)HTTP 400—{"error":{"code":-32600,"message":"Bad Request: Missing session ID"}}http_app(stateless_http=True), this PR)HTTP 200— returns the fulltools/listresultThe 400 is precisely the error reported in #141. With
stateless_http=Truethe same session-less request succeeds, confirming session-less clients (the Assistant) can now list/call tools.Verified on a live Databricks Apps deployment (e2-dogfood staging)
Deployed this branch as a Databricks App and sent session-less requests (no
mcp-session-idheader) directly to<app-url>/mcp, mirroring the Databricks Assistant client from #141:tools/listHTTP 200— full tools list returnedtools/call->healthHTTP 200—{"status":"healthy","message":"Custom MCP Server is healthy and connected to Databricks Apps."}Same requests against the unfixed stateful build return
HTTP 400 "Missing session ID". The fix resolves #141 end-to-end on real Apps infra, not just locally.Fixes #141