Fallback when server launch fail due to create mutex error #8000
Conversation
rokonec
added
the
merge-when-branch-open
|
@rokonec we want this in asap I think and flowing to an rtm sdk build that other teams can try. |
|
Looks like you're closing the runtime repo bug. Do we still need a bug to figure out why it's timing out? Someone else mentioned it wasn't documented. |
|
I feel confident about those changes so I will go ahead and merge it now. |
I would still like to know root cause. Yes it is not documented why would creating named mutex throw IOException with "Timeout" message. I think it might deserve investigation to better understand severity of this. |
|
It would be great if you could open a runtime repo bug describing the configurations where you've seen this. Even if it's not actionable right now. |
Yes, @rokonec is on it. |
…or. (#8024) Fixes #7993 Summary In the MSBuild server, we identify the state of the server via mutexes. Sometimes, for reason yet unknown to us, mutex could throw the exception System.IO.IOException: Connection timed out. When this occurs, we fallback to old behavior building without server. We fixed some of those in #8000, but now found more situations when this happens. Customer Impact MSBuild non-Windows users could have intermittent error when building with dotnet build. This does not affect Visual Studio. Regression? Yes, this is a regression. Testing Unit tests. Risk Low risk. The fix adds additional try-catch blocks to process this situation. Code Reviewers [TODO] Description of the fix Add a try-catch block to catch and process the IOException exception when mutexes are used. Add a new client exit type for this kind of error.
Fixes #7993, dotnet/runtime#75867
Context
There were reported issues, when mutex logic failed with unhandled IOException.
Changes Made
Extend TryLaunchServer try-catch scope to Include opening mutex and if it throws fallback to non-server behavior.
Testing
Unit test, CI.