csharp-sdk

fire-and-forgets tasks but returns as soon as the transport channel completes — without waiting for in-flight handlers. The caller () then disposes service scopes, causing in still-running tool handlers. This is easily triggered by OpenAI's stateless HTTP transport closing the connection while a long-running tool is executing. Changes : Track in-flight handlers with an counter (starts at 1 for the loop itself) and a . Increment before each dispatch, decrement in its . When the count hits zero, signal the TCS. The block of decrements its own count and awaits the TCS if handlers are still running. : Regression test that blocks a tool handler, disposes the transport, then verifies doesn't return until the handler completes. Uses instead of non-generic for .NET Standard 2.0 compatibility. Original prompt This section details on the original issue you should resolve* ObjectDisposedException - IServiceProvider disposed while tool handler execution. Describe the bug Sometimes I get from DI services like the itself or inside the tool call handler. It looks like OpenAI closes the connection for too-long-running tools, and instead of canceling the , the service scope gets disposed. Or the scope gets disposed of without waiting for the handler to cancel cleanly. To Reproduce Steps to reproduce the behavior: 1. Setup: Stateless, Http Transport 2. Call a long-running tool 3. Close the connection to simulate a read-timeout. [!NOTE] I use it with OpenAI OpenAI requires statelessness and closes the connection after some timeout. Expected behavior I expect the handler to either complete or cancel through before the service scope is disposed. Logs Additional context Add any other context about the problem here. Both https://github.com/modelcontextprotocol/csharp-sdk/pull/1401 and https://github.com/modelcontextprotocol/csharp-sdk/pull/1400 are trying to fix this issue. I'd like you to create a PR to fix it as well, in a similar manner, but you shouldn't need to actually track the task instances / maintain a list. It should be enough to just have a counter that's incremented each time and just before ProcessMessageAsync is called, and then ProcessMessageAsync decrements it at the end of its finally block. When the count drops to zero, ProcessMessagesCoreAsync can be allowed to continue / complete. The count can start at 1 and then be Interlocked.Decremented just before it waits on a TaskCompletionSource Task that whoever Interlocked.Decrements the count to 0 will set. Start by writing one or more tests that will fail before the fix and will pass after. ## Comments on the Issue (you are @copilot in this section) Fixes modelcontextprotocol/csharp-sdk#1269 🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.