Skip to content

Conversation

ronmrdechai
Copy link

See title

Motivation and Context

This allows the request ID increment logic to be overwritten by
subclasses. I have a unique need to share sessions' underlying input
and output streams, but not the sessions themselves. This would require
keeping track of request IDs globally to avoid overlap.

Having this logic overridable lets me do that.

How Has This Been Tested?

CI

Breaking Changes

N/A

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

N/A

This allows the request ID increment logic to be overwritten by
subclasses. I have a unique need to share sessions' underlying input
and output streams, but not the sessions themselves. This would require
keeping track of request IDs globally to avoid overlap.

Having this logic overridable lets me do that.
@ronmrdechai
Copy link
Author

For reference, the way I've worked around this currently is that I added these two methods to a subclass of BaseSession:

class MySession(ClientSession):
    _global_request_id: int = 1

    @override
    @property
    def _request_id(self) -> int:
        """
        This setter/getter pair ensures request IDs are globally unique for the
        lifetime of the process. Client session channels for the same MCP server
        are shared, so tracking the request ID globally is required.
        """
        return MySession._global_request_id
​​​
    @_request_id.setter
    def _request_id(self, value: int) -> None:
        diff = value - MySession._global_request_id
        MySession._global_request_id += diff

This is obviously brittle and I'd like a proper interface for it.

@felixweinberger felixweinberger added needs SEP Major changes to structs and features generally require a SEP to be approved. needs motivation When a PR is submitted without clear intent or motivation for the changes. labels Sep 19, 2025
@felixweinberger felixweinberger added needs maintainer action Potentially serious issue - needs proactive fix and maintainer attention and removed needs SEP Major changes to structs and features generally require a SEP to be approved. needs motivation When a PR is submitted without clear intent or motivation for the changes. labels Sep 30, 2025
@felixweinberger felixweinberger self-assigned this Sep 30, 2025
@felixweinberger felixweinberger added needs motivation When a PR is submitted without clear intent or motivation for the changes. and removed needs maintainer action Potentially serious issue - needs proactive fix and maintainer attention labels Sep 30, 2025
@felixweinberger
Copy link
Contributor

felixweinberger commented Sep 30, 2025

Hi @ronmrdechai thank you for this contribution! Apologies for the time it took to get back to this PR.

The solution you have seems like the right way to handle very application specific needs - I don't think we want to take on this flexibility inside the SDK without additional motivation that this is a common request / use case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs motivation When a PR is submitted without clear intent or motivation for the changes.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants