[Failing test]: VS Code extension E2E 'global debug stop removes running apphost' times out waiting for AppHost to stop

[radical]

This flaky E2E test is turning rolling main red. The VS Code extension E2E test global debug stop removes running apphost (debugDashboard.e2e.test.js) intermittently times out after 120s in waitForNoRunningAppHost — the extension still reports the AppHost as running after the debug session stopped. Rolling main has no auto-rerun, so each hit leaves main red until the next clean push.

Red at the tip: run 28224516561 (Jun 26 07:43 UTC).

Failing rolling-main builds (directly verified, Jun 25–26 UTC)

Run	Date (UTC)	Failed shard
28224516561	Jun 26 07:43	Windows
28210695396	Jun 26 01:11	Linux
28196967410	Jun 25 20:01	Windows + Linux
28193852348	Jun 25 19:04	Windows
28192660633	Jun 25 18:43	Linux

Intermittent / flaky: other rolling-main runs in the same window passed the shard (e.g. 28198756323, 28212946076, 28214244629, 28217634886), and which OS fails varies run to run. The same test also flakes on PR CI (Windows) when a PR touches the extension, but the auto-rerun bot rescues those so they rarely show as a final PR failure.

Error message, stack trace, and state at timeout

Error Message:
  1) Aspire debug dashboard E2E
       global debug stop removes running apphost:
     Error: Timed out after 120000ms waiting for AppHost '...\AspireE2E.AppHost\AspireE2E.AppHost.csproj' to stop.
     Last error: <none>
Stack Trace:
     at waitForExtensionState (out\test-e2e\test-e2e\helpers\assertions.js:227:11)
     at async waitForNoRunningAppHost (out\test-e2e\test-e2e\helpers\assertions.js:95:12)
     at async Context.<anonymous> (out\test-e2e\test-e2e\debugDashboard.e2e.test.js)

Captured extension state at the timeout (run 28224516561) — the debug session was torn down but the AppHost is still tracked as running:

"debugSessions": [],          // waitForNoDebugSessions() already succeeded
"stoppingPaths": [],          // AppHost never entered the stopping set
"launchingPaths": [],
"appHosts": [
  { "appHostPath": "...AspireE2E.AppHost.csproj", "appHostPid": 9720, "resources": [] }
],
"hasError": false

With Last error: <none> and hasError: false, no probe failed — the AppHost simply never left the running set within 120s after stopDebugging. This is the same observable behavior as the (closed) product bug #17946 "VS Code extension shows AppHost as running after it has stopped"; this test is effectively its regression test, so an intermittent recurrence (or a test-side timing/observability gap) is the likely cause rather than a slow runner.

Build / shard info, known-issue block, and related issues

• Workflow: CI (ci.yml) → Tests / Run VS Code extension E2E tests (extension-e2e-tests.yml)
• Shard: VS Code extension E2E (Windows, debug-dashboard) / (Linux, debug-dashboard)
• Spec: out/test-e2e/test-e2e/debugDashboard.e2e.test.js, test Aspire debug dashboard E2E > global debug stop removes running apphost
• Runner: windows-latest / ubuntu-latest, Node 20.20.2, VS Code 1.122.1, vscode-extension-tester

{
  "ErrorMessage": "",
  "ErrorPattern": "Timed out after \\d+ms waiting for AppHost .* to stop",
  "BuildRetry": false,
  "ExcludeConsoleLog": false
}

PR-CI evidence (same Windows test): runs 27859653067 and 27880096863 (earlier failures timed out waiting to enter the stopping state; the current main failures time out in waitForNoRunningAppHost waiting to stop — same test, after the #18461 candidate fix changed the asserted state).

Related: #18232 (CI Daily Pulse that surfaced this) · #17946 (closed product bug, likely root cause) · #18412 (re-enable tracking; tests re-enabled in #18464) · #18461 (closed investigation branch) · #18098 (separate zero-to-running teardown flake).

📊 View CI Failure Report

[radical]

Last 10 failures:

Run date	Build Type	Test Name	OS

Summary

Last 24 hrs	Last 7 days	Last 30 days	Most Affected OS	Failure Rate
0	0	0	N/A	0.0%

🔍 Matched by error pattern regex only (no test name filter)

-- Updated on 6/26/2026 8:01:22 PM UTC