fix: propagate reactor context up till transport

[FH-30]

Motivation and Context

When implementing my own custom transport class which has the requirement of passing in a unique JWT Token per incoming request to call tool, I came to realize that context propagation up till the transport's sendMessage function is not working for regular requests but only working for notifications.

Upon further inspection this is because of how sendRequest and sendNotification are implemented in the McpClientSession class.

The sendRequest method creates a response mono and the transport's sendMessage creates a separate mono, the context from the client is only propagated into the response mono but isn't passed into the mono returned by sendMessage. This differs from sendNotification that returns the mono created by the transport's sendMessage back to the client so the context attached by the client gets propagated into the mono in the transport's sendMessage for notifications.

This MR modifies the McpClientSession's sendRequest to explicitly propagate the context into the mono created by transport's sendMessage allowing the transport's sendMessage to access the JWT Token from this context and perform the required logic.

How Has This Been Tested?

yes, ran the existing tests.

Breaking Changes

None

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

[FH-30]

Hi @tzolov, would like to know your thoughts on this, is there any hope of getting this PR merged in? Could let me know as well if you think there is a better solution to this issue, thanks in advance!

[chemicL]

Thank you for the contribution! I agree with the change 100%. As a follow-up it would be nice to add a test to validate the context in the transport sendMessage method but it can be challenging. However, please feel free to open a PR for it.

[FH-30]

Hi @chemicL, regarding this change it actually only solves the problem of context passing for the async client, what do you think about supporting this for the sync client as well? The change however will probably be a breaking change as it requires the signature of the sync client's functions to change as they need to accept the context as an argument and pass it into the underlying mono returned by the underlying async client. Any thoughts on this?

[chemicL]

@FH-30 I don't know your use case that much, but for transitioning between a synchronous world and a reactive one we can rely on Context Propagation. Typically, when it comes to security, as I understand, for instance with Spring Security, the security context can be bound to a ThreadLocal in case of thread-per-request scenarios. In the case of reactive programming, other means should be used - in case of Reactor it can be attached to the Context. Perhaps for your use case you could take advantage of the propagation mechanism, register a ThreadLocalAccessor and rely on its capture into the reactive Context when required? Then you can also enable automatic context propagation if you'd like to rely on the presence of the ThreadLocals. What do you think?