Fix flaky stderr test: call WaitForExit() after WaitForExitAsync() to flush ErrorDataReceived events#1278
Conversation
… ensure ErrorDataReceived events are flushed WaitForExitAsync(CancellationToken) does not guarantee that all ErrorDataReceived events have been dispatched, unlike the synchronous WaitForExit() (no arguments). This caused a race condition where the stderr callback in StdioClientTransportTests might not be invoked before the process was disposed, leading to flaky test failures on macOS net8.0. Co-authored-by: stephentoub <[email protected]>
|
@copilot it looks like this same fix was made and reverted in https://github.com/modelcontextprotocol/csharp-sdk/pull/980/commits... any ideas why? Still believe this is the right fix? |
Looking at PR #980 history: the same So what actually happened was two distinct issues:
The revert only addressed issue 1 and left issue 2 unfixed, which is why the test is still flaky on .NET. This fix addresses issue 2. The |
CreateAsync_ValidProcessInvalidServer_StdErrCallbackInvokedis flaky on macOS net8.0 becauseProcess.WaitForExitAsync()does not guarantee that allErrorDataReceivedevents have been dispatched — only the synchronousWaitForExit()(no-arg overload) does.In
GetUnexpectedExitExceptionAsync, the code intended to flush stderr before building the error message, but was using onlyWaitForExitAsync. The fix adds aWaitForExit()call after it, which is effectively free since the process has already exited:The .NET Framework path already used
WaitForExit()and was not affected.💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.