[browser] Wasm.Build.Tests BuildThenPublishWithAOT (Chrome) times out due to ChromeDriver port-binding race (Connection refused)

[ViveliDuCh]

Build Information

Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1594894
Build error leg or test failing: Wasm.Build.Tests.BuildPublishTests.BuildThenPublishWithAOT (Chrome) / Workloads-ST-Wasm.Build.Tests.BuildPublishTests.WorkItemExecution
Pull request: #133387

Error Message

{
  "ErrorMessage": ["Process timed out", "Connection refused", "ChromeDriver was started successfully"],
  "ErrorPattern": "",
  "BuildRetry": true,
  "ExcludeConsoleLog": false
}

Details

On Ubuntu.2604.Amd64.Open, BuildThenPublishWithAOT (Chrome host) times out with:

System.AggregateException : One or more errors occurred. (Process timed out. Last 20 lines of output:
[wasm test-browser] Connection refused [::ffff:127.0.0.1]:45663 (localhost:45663)
[wasm test-browser] Connection refused [::ffff:127.0.0.1]:45663 (localhost:45663)
[wasm test-browser] Starting ChromeDriver 126.0.6478.0 (...) on port 45663
[wasm test-browser] Only local connections are allowed.
...
[wasm test-browser] ChromeDriver was started successfully.

Console log: https://helixr1107v0xd1eu3ibi6ka.blob.core.windows.net/dotnet-runtime-refs-pull-133387-merge-296b7f4f97714f0dae/Workloads-ST-Wasm.Build.Tests.BuildPublishTests/1/console.88065f7e.log?helixlogtype=result

Interestingly, later in the same log the app under test actually runs to completion (test-main.js exiting ... with result 42), but the harness/xharness wrapper still reports the overall process as timed out, and the paired Workloads-ST-Wasm.Build.Tests.BuildPublishTests.WorkItemExecution work item on the same Helix job reports BadExit. This suggests a startup race between the xharness client connecting and ChromeDriver finishing binding to its local port, rather than a genuine test/product regression — the failing PR (#133387) only bumps runtime-assets test-data dependencies and does not touch WASM/mono/xharness code.

Build Analysis reports non-trivial historical hit rates for these two legs (0.29% and 2.27% respectively) but there is currently no open Known Build Error tracking them.

A prior, similarly-worded issue (#104349, "[browser] Connection refused in 127.0.0.1") existed but was explicitly closed as a "misleading catch-all filter" that hid other distinct bugs (per maintainer comments), rather than being root-caused/fixed. This issue is filed narrower (requiring both the Connection refused and ChromeDriver was started successfully lines to match) to avoid repeating that problem.

Note

This issue was drafted with the assistance of GitHub Copilot at the request of @ViveliDuCh, based on analysis of Build Analysis results for PR #133387.

Known issue validation

Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1594894
Error message validated: [Connection refused ChromeDriver was started successfully]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 9/23/2026 6:23:40 PM UTC

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[lewing]

With the ErrorMessage as written this will pass every failure that has to retry connections in the log.

[pavelsavara]

With the ErrorMessage as written this will pass every failure that has to retry connections in the log.

Agreed, I added Process timed out to the filter