-
Notifications
You must be signed in to change notification settings - Fork 2k
Context state inheritence issue when composing servers #3794
Copy link
Copy link
Closed
Labels
bugSomething isn't working. Reports of errors, unexpected behavior, or broken functionality.Something isn't working. Reports of errors, unexpected behavior, or broken functionality.potential-duplicateBot-suggested duplicate awaiting human review. Auto-closes after 3 days if unchallenged.Bot-suggested duplicate awaiting human review. Auto-closes after 3 days if unchallenged.serverRelated to FastMCP server implementation or server-side functionality.Related to FastMCP server implementation or server-side functionality.
Metadata
Metadata
Assignees
Labels
bugSomething isn't working. Reports of errors, unexpected behavior, or broken functionality.Something isn't working. Reports of errors, unexpected behavior, or broken functionality.potential-duplicateBot-suggested duplicate awaiting human review. Auto-closes after 3 days if unchallenged.Bot-suggested duplicate awaiting human review. Auto-closes after 3 days if unchallenged.serverRelated to FastMCP server implementation or server-side functionality.Related to FastMCP server implementation or server-side functionality.
What happened?
When a child FastMCP server is mounted on a parent, middleware registered on
the parent can set session state via
context.fastmcp_context.set_state(...).However, that state is NOT visible to tools running on the child server: calling
ctx.get_state(...)inside a child tool returnsNone.This only occurs when no shared
session_state_storeis provided.Without a shared store, the parent and child maintain
separate state namespaces and the child cannot see state written by the parent
middleware.
We expected the state set by the parent middleware to be accessible to downstream tools because of the chaining of middleware.
These defaults state scoping rules are not documented.
Example Code
Version Information