From 31180f1edd266336d66eede368b982f035e24ed0 Mon Sep 17 00:00:00 2001 From: Matthew Leibowitz Date: Thu, 11 Jun 2026 17:37:26 +0200 Subject: [PATCH] Add blame-hang-timeout to .NET test runs so hangs fail fast The macOS (.NET Core) test job intermittently hangs for 30 min to 3 h (vs a healthy ~8 min) and occasionally hits the 180-min job timeout. There is currently no per-test or process-level hang timeout, so a stuck test host burns to the job cap and AzDO retries the whole tests-netcore step up to 3x. Add a process-level safety net via the VSTest blame-hang collector in the shared RunDotNetTest helper (covers all .NET Core desktop test projects run by the tests-netcore target). 15m is safely above the worst observed passing run (~13 min) so it won't false-fire, while bounding a true hang. A 'none' dump type avoids large artifacts. --blame-hang-timeout auto-enables blame mode, so no separate --blame flag is needed. The device/WASM runner path (RunDeviceRunnersTest) is intentionally left unchanged: those tests run in-process inside a MAUI/Blazor host and do not use the VSTest blame collector. Refs #4139 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- scripts/infra/tests/test-shared.cake | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/scripts/infra/tests/test-shared.cake b/scripts/infra/tests/test-shared.cake index e5bb57133b1..669107e7b91 100644 --- a/scripts/infra/tests/test-shared.cake +++ b/scripts/infra/tests/test-shared.cake @@ -89,7 +89,9 @@ void RunDotNetTest( Verbosity = DotNetVerbosity.Normal, ArgumentCustomization = args => { args = args - .Append("/p:Platform=\"AnyCPU\""); + .Append("/p:Platform=\"AnyCPU\"") + .Append("--blame-hang-timeout").Append("15m") + .Append("--blame-hang-dump-type").Append("none"); if (COVERAGE) args = args .Append("/p:CollectCoverage=true")