-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Fix flakiness/timeout in gRPC template tests #19982
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
642ca2c
to
f89277a
Compare
Did the change in #19252 do it? |
Ah that's probably it. |
You may have fixed the test failure flakiness, but you haven't fixed the hang. |
Argghh, I'll see what's causing the hang now. |
👀 |
f89277a
to
0910388
Compare
Do not search for port number for cases where we are testing for failure.
This reverts commit c49f169.
4c1bcc2
to
9a2de83
Compare
9a2de83
to
00a4267
Compare
FYI don't review yet, still testing a few hypotheses. |
Can we please skip these tests while investigating? |
?? These tests are skipped in the main runs... |
Aren't the tests causing quarantined runs to timeout? |
Were causing, hence they were skipped. |
I have fixed the tests already, I'm just trying to pin down a more specific cause for the test hangs. And no, the whole point is to figure out what was happening in these tests so we shouldn't be skipping them. |
Okay with the latest test failure (https://dev.azure.com/dnceng/public/_build/results?buildId=573237&view=ms.vss-test-web.build-test-results-tab&runId=17971944&paneView=debug&resultId=100107), I think I've confirmed that:
Having fixed both issues, I think we are ready to run these tests under quarantine again. |
[SkipOnHelix("Not supported queues", Queues = "Windows.7.Amd64;Windows.7.Amd64.Open;OSX.1014.Amd64;OSX.1014.Amd64.Open")] | ||
[QuarantinedTest("https://github.com/dotnet/aspnetcore/issues/19716")] | ||
public async Task GrpcTemplate() | ||
{ | ||
// Setup AssemblyTestLog | ||
var assemblyLog = AssemblyTestLog.Create(Assembly.GetExecutingAssembly(), baseDirectory: Project.ArtifactsLogDir); |
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.
Why are we doing this here instead of the normal way?
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.
Glad you asked. Normally, we would be using LoggedTest
but that requires the use of AspNetTestFramework
xunit test framework. This cannot be used in template tests since they already use their own test framework:
[assembly: TestFramework("Microsoft.AspNetCore.E2ETesting.XunitTestFrameworkWithAssemblyFixture", "ProjectTemplates.Tests")] |
I think it's possible to combine the logic of the two xunit frameworks but that's a rather large undertaking that doesn't seem appropriate here.
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.
The test log stuff seems odd, but I like the overall change
Do not search for port number for cases where we are testing for failure.
I don't know how these tests ever passed on macOS.