[Issue]: lifecycle-windows-http-install flakes on the Windows job, failing unrelated PRs

[rominf]

Problem Description

The lifecycle-windows-http-install E2E scenario fails intermittently on the windows-build-and-test job, in the Acceptance install lifecycle step. It is not tied to any particular change — it has hit four unrelated pull requests in the same afternoon, and passes on re-run without any code change.

The failure is a transport error while the PowerShell installer fetches from the local test HTTP server:

rocm-cli installer: failed to download
http://127.0.0.1:64877/rocm-cli-windows-amd64.zip.sha256:
An error occurred while sending the request.

Step failed:
Step panicked. Captured output: installer did not report signature verification
13 scenarios (12 passed, 1 failed)
FAIL: 'lifecycle-windows-http-install' was expected to pass on this host but FAILED — a regression.

The installer downloads the archive itself successfully and then fails on the immediately following .sha256 request to the same server, which points at the local server or the connection handling rather than at the artifact.

Observed on

Four pull requests, none of which touch the installer or the Windows path:

• fix(install): delete the SDK archive once it is extracted #166 — deletes a cached tarball after extraction (Rust only)
• test(proc-lifecycle): stop counting a zombie as a running process #169 — changes two Linux-only unit-test assertions
• fix(uv): colocate the uv cache with the ROCm CLI data dir #170 — sets a uv environment variable
• feat(storage): add rocm storage to see and reclaim disk space #172 — adds a new CLI subcommand

#166 passed on re-run with no changes.

Impact

Because the scenario is listed as expected-to-pass, the failure is reported as a regression and turns the whole job red. Every affected PR needs a manual re-run, and a genuinely red Windows job is easy to dismiss as "probably that flake again" — which is how a real Windows regression gets missed.

Suggested Fix

Worth investigating why the second request to the local server fails so much more often than the first — a connection being closed between requests, a port reused before it is ready, or a missing retry around the metadata fetch. If the root cause is not quickly findable, a bounded retry on the installer's metadata download would remove the false signal.

Additional Information

Reported while landing unrelated disk-usage work; I did not investigate the installer or the test server itself.

[rominf]

Update: the failure rate climbed sharply over the course of one afternoon, across four unrelated pull requests.

PR	Change	Consecutive failures before green
#166	Rust-only cache cleanup	1, then green
#169	Linux-only test assertions	2, then green
#172	new CLI subcommand	3, then green
#170	one environment variable	5, still failing

Every failure has the same signature — install.ps1 failing to reach the test's local HTTP server on 127.0.0.1, sometimes on the .zip and sometimes on the .sha256:

failed to download http://127.0.0.1:<port>/rocm-cli-windows-amd64.zip:
An error occurred while sending the request.

The increasing count across the afternoon suggests a degrading runner or network condition rather than a fixed-probability flake.

#169 is worth singling out as proof the trigger is not in the changes under test: it modifies only #[cfg(target_os = "linux")] unit-test assertions, which cannot affect a PowerShell installer on Windows, and it still failed twice before going green.