fix: retry HTTP download in install.ps1 on transient failure - #183
Open
juhovainio wants to merge 1 commit into
Open
fix: retry HTTP download in install.ps1 on transient failure#183juhovainio wants to merge 1 commit into
juhovainio wants to merge 1 commit into
Conversation
Invoke-WebRequest had no retry logic, so a single transient connection failure (e.g. connection reset, or the server-side listener not yet ready) would abort the install outright. This is the exact failure signature behind the intermittent lifecycle-windows-http-install E2E flake, and it also affects real production HTTP downloads. The expectations.toml flaky mechanism was considered but doesn't fit here: it only tolerates an unexpected pass of a known-bug xfail scenario, not an unexpected fail of an expect-pass scenario, so it can't be reused to tolerate this failure mode without a design change to the expectation system itself. Save-File now retries the Invoke-WebRequest call up to 3 times with a short increasing backoff before failing. The local file:// (Copy-Item) path is untouched since it isn't networked and isn't implicated in the flake. Signed-off-by: Juho Vainio <juho.vainio@amd.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Save-File'sInvoke-WebRequestcall had no retry logic: a single transient connection failure (e.g. a connection reset, or the loopback/server-side listener not yet fully ready) aborted the install outright.lifecycle-windows-http-installE2E flake seen onmainand on PR test(e2e): tolerate intermittent EAI-7423 XPASS on the Strix Halo Ubuntu lane (EAI-7853) #182's merge queue attempt ("An error occurred while sending the request"), and it also affects real-world production HTTP downloads, not just the test's loopback server.Save-Filenow retries theInvoke-WebRequestcall up to 3 times with a short increasing backoff (250ms/500ms) before failing. The localfile://(Copy-Item) branch is untouched since it isn't networked and isn't implicated in the flake.Why not use
expectations.toml'sflakymechanism instead?I looked into marking the scenario as flaky via the existing xfail matrix, but it doesn't fit this failure shape:
flakyonly tolerates an unexpected pass of a scenario that's expected to fail as a known bug (an XPASS).lifecycle-windows-http-installis an ordinaryExpectPassscenario that intermittently fails outright — the opposite case, which the reconciliation logic intests/e2e-cucumber/tests/e2e.rsalways treats as a fatalunexpected_fail, with no existing tolerance path.Reusing/extending that mechanism to also cover unexpected-fail-of-expect-pass was flagged in PR #182's review discussion as a bigger design decision (a quarantine marker with an expiry was suggested as the better long-term shape) that shouldn't be decided ad hoc here. A genuine reliability fix at the actual failure site is more proportionate, and improves the real installer besides.
Test plan
lifecycle-windows-http-install, should pass reliably (or at minimum no longer show this exact failure signature if it's hit again transiently, since it'll now retry).install.ps1stays clean.pwshavailable in this (Linux/WSL) dev environment, and there's no Pester/unit suite forinstall.ps1— it's only exercised via the Windows E2E cucumber scenarios in CI.