[release/5.0] (deps): Bump src/submodules/googletest from 4517697 to c9461a9

[dependabot]

Bumps src/submodules/googletest from 4517697 to c9461a9.

Commits

• c9461a9 Update GCC/Clang Linux tests to use Bazel 5.0.0
• ea55f1f Address conversion warning by explicitly casting to size_t
• 0e40217 Add a 3-arg overload for ResultOf() matcher that takes a description string f...
• 06519ce Merge pull request #3751 from noiseless:gtest-help-test-OpenBSD
• 504eb98 Merge pull request #3746 from IYP-Programer-Yeah:use-constant-time-lookup-for...
• 43efa0a Merge pull request #3617 from Bagira80:fix_3616
• d6841c0 Apply requested changes by using std::inserter with move.
• 631f4f9 Fix gtest-help-test failure on OpenBSD
• 14aa11d Merge pull request #3724 from jjfvanderpol:main
• 25ad42a GetCurrentOsStackTraceExceptTop (both the method of UnitTestImpl and the wrap...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[ghost]

Hi @dependabot[bot]. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document.
Otherwise, please add tell-mode label.

[dougbu]

Another servicing branch flaky test (see #40469). @HaoK is this a known problem or something w/ a known fix that can be backported to 5.0.x (soon)❔

No entries matched by 'Could not start stdout file redirection to 'Q:\std' with application base 'C:\h\w\C41F0A59\t\6baeabc8765743baa76831de57d23b14\'.'
Expected: True
Actual:   False

Stack trace
   at Microsoft.AspNetCore.Server.IIS.FunctionalTests.EventLogHelpers.AssertEntry(String regexString, IEnumerable`1 entries, Boolean allowMultiple) in /_/src/Servers/IIS/IIS/test/Common.FunctionalTests/Utilities/EventLogHelpers.cs:line 72
   at Microsoft.AspNetCore.Server.IIS.FunctionalTests.EventLogHelpers.VerifyEventLogEvent(IISDeploymentResult deploymentResult, String expectedRegexMatchString, ILogger logger, Boolean allowMultiple) in /_/src/Servers/IIS/IIS/test/Common.FunctionalTests/Utilities/EventLogHelpers.cs:line 25
   at Microsoft.AspNetCore.Server.IIS.FunctionalTests.LoggingTests.InvalidFilePathForLogs_ServerStillRuns(TestVariant variant) in /_/src/Servers/IIS/IIS/test/Common.FunctionalTests/LogFileTests.cs:line 83
--- End of stack trace from previous location ---

[dougbu]

@adityamandaleeka @rafikiassumani-msft @mkArtakMSFT we need to keep on top of flaky test fixes in our servicing branches because the window the branches are open doesn't leave us much time for retrying PRs and the impact of flakiness here can be delayed releases. Please give these problems high urgency in your teams.

[dougbu]

Sorry @HaoK for the missing information above. The variant was (variant: Server: IIS, TFM: net5.0, Type: Standalone, Arch: x64, Host: InProcess) and the relevant files files (in case retrying loses them) are

• https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-aspnetcore-refs-pull-40467-merge-41abaa4cabbf4828ae/IIS.FunctionalTests--net5.0/1/LoggingTests_CheckStdoutLoggingToFile-Server_IIS%2C_TFM_net5.0%2C_Type_Standalone%2C_Arch_x64%2C_Host_InProcess.log?sv=2019-07-07
• https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-aspnetcore-refs-pull-40467-merge-41abaa4cabbf4828ae/IIS.FunctionalTests--net5.0/1/net5.0_global.log?sv=2019-07-07
• https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-aspnetcore-refs-pull-40467-merge-41abaa4cabbf4828ae/IIS.FunctionalTests--net5.0/1/console.e8ddbb6c.log?sv=2019-07-07
• https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-aspnetcore-refs-pull-40467-merge-41abaa4cabbf4828ae/IIS.FunctionalTests--net5.0/testResults.xml?sv=2019-07-07
• https://helixre8s23ayyeko0k025g8.blob.core.windows.net/dotnet-aspnetcore-refs-pull-40467-merge-41abaa4cabbf4828ae/IIS.FunctionalTests--net5.0/c627c157-ff10-4612-8017-ecd234a3eda4.log?sv=2019-07-07

[HaoK]

Honestly my suggestion given servicing branches are low volume and we care more about reducing flakeiness is to just add 3 local retry to the helix reruns across the board in our servicing branches for some of the important namespaces, say Microsoft.AspNetCore.Server.IIS.*

[HaoK]

The quarantine process for release branches should be just to continuously add more tests to the local retry as opposed to trying fix things in servicing, but we should fix the tests in main, 3 retries should be plenty for every test that actually is running on every PR in main

[dougbu]

add 3 local retry to the helix reruns across the board in our servicing branches for some of the important namespaces, say Microsoft.AspNetCore.Server.IIS.* … as opposed to trying fix things in servicing

@HaoK I'm interested in your idea but unsure about neglecting to backport worthwhile test-only changes to our servicing branches. @adityamandaleeka @rafikiassumani-msft @mkArtakMSFT are you comfortable going this route❔

If yes, @HaoK could you please fire up a PR❔

[HaoK]

Doesn't look like helix retry is in 5.0, but I can open a PR in 6.0 demonstrating what I mean tomorrow

[adityamandaleeka]

@HaoK is this a known problem or something w/ a known fix that can be backported to 5.0.x (soon)❔

I did a quick search and didn't see any prior issues for this error in InvalidFilePathForLogs_ServerStillRuns, so I'd be surprised if we've done anything in later releases that de-flakes this.

Do we have any evidence of there being an elevated error rate on this test in servicing branches, or did we just get unlucky here? If the latter, it's frustrating, but I don't know what we should do differently with respect to how we treat the servicing branches. I'm curious to hear what others think.

Zooming out from this specific case, it is worth discussing our approach towards backporting test de-flaking changes to servicing branches (e.g. should we default to doing that in every case?).

[HaoK]

Nope, just unlucky, but the server functional tests inherently have wait for logs/event logs so that pattern inherently seems to have some tiny amount of flakiness, like if the OS gets busy just long enough for the test to give up waiting and fail.

My feeling is that since servicing branches are not something we actively work in, then the drawback of global automatic retries masking flakiness is not much of an issue since it looks like we've only had 9 builds of release/5.0 in the past 30 days? If there's concern about slipping release dates due to having to manually retry builds, then automatic retries would address that cheaply, especially since this is a test that has no history of flakiness, so it's also the only solution for this kind of unlucky failures...