By adding an optional idle timeout termination to the StreamableHTTPServerTransport, this PR allows the stateful server to close long-idle sessions to avoid memory leak issues when the client does not terminate the session as expected

These changes comply with the specifications for Streamable HTTP transports session management in the MCP protocol.

Meanwhile, optimized the logic for transport termination and session management without affecting existing functionality, including:

• Moved the transport termination after handle stateless requests to the finally block
• Called the terminate function directly after the transport connect finished
• Removed the condition of the transport is not terminated in the finally block of the run_server in handle_stateful_request, because that instances should be cleared even if transport terminates first
• The manager returns 404 instead of 400 when it receives a non-existent session ID, because this might be due to the server actively terminating the transport

Motivation and Context

#1116 addressed the memory leak issue caused by session not terminating in stateless requests, but in stateful requests, if the client does not close the session as expected, the session on the server will never be closed, leading to a similar memory leak issue.

This PR adds an optional idle timeout parameter to StreamableHTTPServerTransport, a context manager for tracking idle status, and an _idle_timeout_terminate method. When the idle timeout parameter is set, an _idle_timeout_terminate task is initiated when transport connect is called. Once the transport does not receive or hanle any requests within the timeout period, the transport will be automatically terminated. To ensure that correctly tracks the idle status of transport, the handle_request method of the transport needs to be called within the context manager.

How Has This Been Tested?

I have added a test to verify that the transfer and session will exist before the idle timeout and will be terminated after the idle timeout.

Breaking Changes

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