[Ladislau Szomoru (lszomoru)]

The Prepare WSL Dev Container smoke tests step keeps failing and then passing on a re-run of the same commit, even after #342344. Since #343812, #343815 and #344338 it runs in Windows / Electron-Smoke (shard 1/3) on the 1ES pool (1es-vscode-oss-windows-2022-x64), and it still fails the same way there: on 2026-10-27 that job failed 5 times between 16:27 and 19:00 UTC; 2 runs were fixed by a manual re-run and 3 were left red.

Cause

I went through the failed attempts of every re-run Code OSS run between 2026-10-09 and 2026-10-23 and grouped them by the error in the job log. There were 32 failed prep attempts:

Failures	When	What failed
18	all on 2026-10-22, after #342344	apt-get inside the WSL distro stalls on archive.ubuntu.com / security.ubuntu.com: 17 hit the 300 s Invoke-Wsl timeout, 1 failed apt-get update with File has unexpected size … Mirror sync in progress?
13	before #342344	the old inbox WSL + 2021 kernel: processes crashed (exit 139/134, a containerd segfault, dpkg-deb killed) or wsl --import hung until the 15 minute step timeout. #342344 already fixed this.
1	2026-10-09	the Ubuntu rootfs download from cloud-images.ubuntu.com timed out (curl exit 28 after 180 s at ~700 kB/s), and curl's --retry never ran

The 2026-10-27 failures on the 1ES pool are the first kind again. For example, in 40546831050 / job 122340803832 the 14.1 MB jammy/universe package index from archive.ubuntu.com takes 2 min 31 s, the next indexes are just as slow, and apt-get update is killed by the 300 s timeout; in 40565015771 / job 122404096673 the same index takes 3 min 50 s. In both, the rootfs and server downloads took 1–3 s.

So nearly every flake left after #342344 comes from one thing: the step downloads ~130 MB of apt indexes and packages from Canonical's public archive. From the Azure-hosted agents that archive sometimes slows to a few hundred kB/s or stalls (healthy runs fetch the 80 MB of packages in about 1 s). Then apt-get update + apt-get install runs past the 300 s budget for that command. apt was already retrying (the Ign: lines), but every retry went back to the same slow mirror.

The rootfs download wasn't being retried because of a flag mismatch: curl only retries until --retry-max-time (120 s) has passed, and that is shorter than --max-time (180 s), so by the time a slow transfer times out the retry window is already closed.

Fix

In test/smoke/wslDevContainer.ps1:

• Point the distro's apt sources at azure.archive.ubuntu.com, the Azure-hosted Ubuntu mirror, and set Acquire::Retries "5" in /etc/apt/apt.conf.d/80-retries. This is what build/azure-pipelines/linux/build-snap.sh does (test/sanity/scripts/run-ubuntu.sh also switches to the mirror, without the retries). Unlike those scripts, this one also rewrites security.ubuntu.com, because both hosts stalled; the mirror serves jammy-security too. The pinned jammy rootfs keeps its sources only in /etc/apt/sources.list (no sources.list.d entries, no deb822 ubuntu.sources), and the sed rewrites all 10 entries there (7 archive, 3 security).
• In Save-Download:
  • Abort transfers that stay below 1 MiB/s for 30 s (--speed-limit 1048576 --speed-time 30). At that speed the 210 MiB server and 325 MiB rootfs downloads can't finish within --max-time anyway, so the transfer is stopped after ~30 s and retried on a fresh connection.
  • Raise --retry-max-time from 120 to 300 s, above --max-time (180 s). Otherwise a transfer that is fast enough to pass the speed limit but too slow to finish (about 1.2–1.8 MiB/s) still runs into --max-time after the retry window has closed and is never retried. A single download now takes at most about 300 + 180 s, which leaves room for the ~2 minutes the rest of a healthy setup takes within the 15 minute step timeout.

The same script runs in the Azure Pipelines Windows smoke job (-CI AzureDevOps in build/azure-pipelines/win32/steps/product-build-win32-test.yml, on 1es-windows-2022-x64). -CI only changes where the run ID, workspace and outputs come from, so that job gets the same fix. This PR's checks don't run it.

How this relates to the other recent changes

• ci: run Windows PR checks on vscode-large-runners-windows-8-core #343812 moved the Windows PR checks to vscode-large-runners-windows-8-core, ci: run more Windows smoke test shards and split the Windows remote tests #343815 split the Windows smoke tests into 3 shards, and Fix WSL smoke test runner to prevent hung PR checks #344338 keeps shard 1, which has the WSL suite, on the 1ES pool, because the larger runners intermittently freeze while WSL2 provisions a distribution. Those changes are about which machine runs the step. This PR changes where the step downloads from, so they don't overlap, and the 2026-10-27 failures show that the 1ES pool is affected too.
• None of them touched test/smoke/wslDevContainer.ps1; the branch merges cleanly into main.

Cleanup step timeouts

All 3 Clean up WSL Dev Container smoke tests timeouts in the window (2026-10-13, 2026-10-16 ×2) came after a prep step that had hung under the old WSL. Before #342344, cleanup called wsl.exe without a timeout and hung on the same stuck utility VM. #342344 put every cleanup call behind Invoke-WslExe timeouts. Since then the only cleanup failures were in cancelled runs (the prep was cancelled mid-import and ext4.vhdx was still locked), so this PR leaves cleanup alone.

Example runs

Failed attempts, each passing on re-run:

• 39801485564 / job 119903240581: containerd (28 MB) from archive.ubuntu.com doesn't finish within 3 minutes, so the 300 s timeout hits
• 39859083690 / job 120104982682: apt-get update takes 3 min 5 s at 262 kB/s, then a package download times out (Ign:)
• 39859572070 / job 120106639029: the install stalls on runc
• 39859943966 / job 120107874676: apt-get update stalls for 4.5 minutes
• 39754509328 / job 119744201113: apt-get update exits 100 with Mirror sync in progress? at 414 kB/s
• 37986718258 / job 114010424110: rootfs download times out with no retry

A healthy re-run for comparison: 39859083690 attempt 2 / job 120119525911, where apt-get update takes 6 s and the packages come down at 106 MB/s.

Validation

Locally (macOS, PowerShell 7.5.2, curl 8.7.1):

• [System.Management.Automation.Language.Parser]::ParseFile('test/smoke/wslDevContainer.ps1', …): passed, 0 parse errors.
• Extracted etc/apt/ from the pinned rootfs (ubuntu-jammy-wsl-amd64-ubuntu22.04lts.rootfs.tar.gz, 20250318) and ran the script's sed on its sources.list: passed, 10 of 10 entries point at azure.archive.ubuntu.com, none left on another host.
• Expanded the here-string the way PowerShell does and ran its new lines with /bin/bash -euc through ProcessStartInfo.ArgumentList, the way Invoke-WslExe runs them: passed, exit 0, and 80-retries contains Acquire::Retries "5";.
• Scaled-down curl test against a local throttled server: a transfer above the speed limit that can't finish in time was not retried with --retry-max-time < --max-time (1 request, exit 28) and was retried with --retry-max-time > --max-time; a transfer below the speed limit was aborted after --speed-time and retried.

In CI, this PR's own Windows / Electron-Smoke (shard 1/3) (40662131812 / job 122728151515) ran the step on the 1ES pool and passed: all 63 Get: lines are from azure.archive.ubuntu.com and none from archive.ubuntu.com or security.ubuntu.com; apt-get update fetched 50.9 MB in 5 s and the 79.9 MB of packages in 4 s; the rootfs and server downloads took 3 s and 2 s; the whole prep took 2 min 0 s, and Agents Window (WSL Dev Container AgentHost) passed (18 passing, 0 failing). The first commit had already run the step twice on the 1ES pool with the same result (apt-get update fetched 50.9 MB in 6 s): 39945462825 / job 120386997724 (prep 1 min 41 s) and 40658439457 / job 122715233630 (prep 2 min 0 s).

🤖 Generated with Claude Code

[Copilot]

🟢 Approval recommended

The changes are narrowly scoped to download reliability, preserve existing failure handling, and have no identified correctness defects.

No open issues 🎉

What changed in this PR

This PR targets remaining download-related flakes in VS Code’s Windows WSL Dev Container smoke setup, following the WSL upgrade in #342344.

Changes:

• Switch Ubuntu apt sources to the Azure mirror and configure five download retries.
• Abort sustained low-speed curl transfers early to leave time for retries.

No actionable findings remain. Windows/WSL runtime validation still depends on CI.

File	Description
test/​smoke/​wslDevContainer.ps1	Updates apt mirror and retry settings, and adds curl low-speed limits.

_{Review effort: Balanced}