Skip to content

fix: propagate context to MCP server clean #1677

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

CakeCrusher
Copy link
Contributor

TLDR:
The context passed by the InstrumentedStreamWriter.send was being mutated by processes preceeding InstrumentedStreamReader resulting in disjointed MCP traces.
image
By adding instrumentation at _handle_request (an earlier state in the program flow) the original message composed by InstrumentedStreamWriter.send is preserved. This context is then propagated at the server level.
image

the context is detached by the same method it was being detached before, through InstrumentedStreamReader.

@CakeCrusher CakeCrusher requested a review from a team as a code owner May 23, 2025 18:59
@dosubot dosubot bot added the size:S This PR changes 10-29 lines, ignoring generated files. label May 23, 2025
@CakeCrusher
Copy link
Contributor Author

Hi @mikeldking heres the new MCP propagation PR in case i lost you in my mess

Copy link
Contributor

@mikeldking mikeldking left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems to be failing tests. Can you check the failures?

@@ -1 +1 @@
__version__ = "1.3.0"
__version__ = "1.3.1"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
__version__ = "1.3.1"
__version__ = "1.3.0"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does CD handle it?

@@ -79,6 +87,7 @@ def _instrument(self, **kwargs: Any) -> None:
def _uninstrument(self, **kwargs: Any) -> None:
unwrap("mcp.client.stdio", "stdio_client")
unwrap("mcp.server.stdio", "stdio_server")
unwrap("mcp.client.session", "ClientSession.call_tool")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't match the method instrumented above?

@dosubot dosubot bot added size:M This PR changes 30-99 lines, ignoring generated files. and removed size:S This PR changes 10-29 lines, ignoring generated files. labels May 31, 2025
@CakeCrusher CakeCrusher force-pushed the fix_mcp_ctx_propagation_clean branch from 85b33d4 to cd5cf15 Compare May 31, 2025 17:58
@CakeCrusher CakeCrusher force-pushed the fix_mcp_ctx_propagation_clean branch from cd5cf15 to d1d3c40 Compare May 31, 2025 18:01
@CakeCrusher
Copy link
Contributor Author

@mikeldking
The problem with the tests seems to be that the socket network restrictions that exist in the CI actions environment is provoking the test_hello inside test_instrumentor to stall.
For the time being I removed testing on test_hello inside test_instrumentor.
I can think of 3 better solutions:

  1. Add a github env variable that you can use to conditionally run transport options sse and streamable-http. This enables complete testing on local but limited testing on CICD runner environment.
  2. Resolve the network limits only on this MCP.
  3. Edit restrictions on CICD liklely related to pytest-socket plugin.

Comment on lines +113 to +123
token = None
try:
# Message has been deserialized, we need to extract the traceparent
_meta = {"traceparent": args[1].params.meta.traceparent}
ctx = propagate.extract(_meta)
token = context.attach(ctx)
finally:
res = await wrapped(*args, **kwargs)
if token:
context.detach(token)
return res
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current try/finally structure could lead to unexpected behavior. If an exception occurs during context extraction, the wrapped function would still execute in the finally block, which is likely not the intended behavior.

Consider restructuring like this:

token = None
try:
    # Message has been deserialized, we need to extract the traceparent
    _meta = {"traceparent": args[1].params.meta.traceparent}
    ctx = propagate.extract(_meta)
    token = context.attach(ctx)
    
    # Execute the wrapped function inside the try block
    res = await wrapped(*args, **kwargs)
    return res
finally:
    # Only detach if we successfully attached
    if token:
        context.detach(token)

This ensures the wrapped function only executes if context extraction succeeds, while still guaranteeing context detachment in all cases where it was attached.

Suggested change
token = None
try:
# Message has been deserialized, we need to extract the traceparent
_meta = {"traceparent": args[1].params.meta.traceparent}
ctx = propagate.extract(_meta)
token = context.attach(ctx)
finally:
res = await wrapped(*args, **kwargs)
if token:
context.detach(token)
return res
token = None
try:
# Message has been deserialized, we need to extract the traceparent
_meta = {"traceparent": args[1].params.meta.traceparent}
ctx = propagate.extract(_meta)
token = context.attach(ctx)
# Execute the wrapped function inside the try block
res = await wrapped(*args, **kwargs)
return res
finally:
# Only detach if we successfully attached
if token:
context.detach(token)

Spotted by Diamond

Is this helpful? React 👍 or 👎 to let us know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:M This PR changes 30-99 lines, ignoring generated files.
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

2 participants