-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Better BuildServerTestFixtureBase dispose timeouts #29544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
ad2ff4b
to
1881e05
Compare
1881e05
to
bc95b12
Compare
@halter73 Since we moved the Razor SDK into the SDK repo, we'll actually be removing this code from our repo shortly (working on a branch for that now). These integration tests are now in the SDK repo on a different stack. |
else | ||
{ | ||
var output = writer.ToString(); | ||
throw new TimeoutException($"Shutting down the build server at pipe {PipeName} took longer than expected.{Environment.NewLine}Output: {output}."); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wondering if instead the code should just output a warning e.g. using an ITestOutputHelper
. Unfortunately that would require changing all uses of derived fixtures. Thoughts i.e. is this case actually an error worth crashing the test host about❔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After this change, the tests fail rather than crash the testhost. I don't know if a warning would be better, but it sounds like this isn't going to be around for much longer. This is a simple fix that seems to me to be strictly better than what we have now.
@captainsafia How shortly is shortly? The failure rate on this seems really high. It's hard to say exactly how high because how the failure crashes the testhost, but I was looking at multiple consecutive failures and it doesn't seem to just be some transient infrastructure flakiness. If these tests aren't being removed today, I think we should merge this so we don't waste time for the next person on build-ops. |
Hi @captainsafia. It looks like you just commented on a closed PR. The team will most probably miss it. If you'd like to bring something important up to their attention, consider filing a new issue and add enough details to build context. |
Two consecutive builds of our main branch failed yesterday because of BuildServerTestFixtureBase.Dispose() timeouts, but it wasn't immediately obvious this was the cause.
https://dev.azure.com/dnceng/public/_build/results?buildId=960451&view=results
https://dev.azure.com/dnceng/public/_build/results?buildId=960598&view=results
I still don't know exactly which test(s) lead to this timeout. Is this something that can happen for any test using BuildServerTestFixtureBase or only certain tests? There are many concurrent tests at the time of the crash so it's hard to determine.
Furthermore, having test fail in this way makes our CI test failure reporting inaccurate and make it seem as if tests relying on BuildServerTestFixtureBase are less flaky than they really are.
After this change, we should see an actual test failure when there's a timeout shutting down the build server instead of having to download artifacts to see the real exception thrown from a Timer thread.
Previous error in build output:
Previous Windows_Test_Logs/Release/Microsoft.NET.Sdk.Razor.IntegrationTests_net6.0_x64.log:
New error in build output: