Tagging subscribers to this area: @akoeplinger, @matouskozak, @simonrozsival
See info in area-owners.md if you want to be subscribed.

linux_V8Version=14.7.173 doesn't exist on canary CDN. We validate if chrome snapshot url exists but we don't check if v8 does.

🤖 Copilot Code Review — PR #126802

Holistic Assessment

Motivation: Justified — the automated Chrome version bump blindly updated linux_V8Version to 14.7.173, but that V8 binary doesn't exist on the GCS canary CDN for linux64. This would break V8/d8 provisioning in CI. Adding a pre-flight CDN availability check prevents this class of failure going forward.

Approach: Sound — using an HTTP HEAD request against the CDN is lightweight and correct. Falling back to the existing V8 version from BrowserVersions.props when the new binary isn't available is the right behavior. The Chrome version is still bumped independently, which is correct since Chrome and V8 (d8) are separate downloads.

Summary: ✅ LGTM. The two issues flagged by the earlier review (Windows platform ID mismatch win64→win32, and fragile OS identifier fallback) have both been fixed in commit 6856460. The code is now correct and consistent with the rest of the file. One minor suggestion below.

Detailed Findings

✅ V8 Platform ID Mapping — matches provisioning targets

GetV8BinaryUrl now maps "Linux_x64" → "linux64" and "Win_x64" → "win32", which exactly matches the _V8PlatformId values in eng/testing/wasm-provisioning.targets (lines 69 and 109). The constructed URLs are identical to what CI uses to download V8 binaries:

(storage.googleapis.com/redacted)

✅ OS Identifier Validation — now consistent with the file

The V8 version node name lookup (lines 209–213) now explicitly checks for both "linux" and "windows" (case-insensitive) and throws LogAsErrorException for unknown identifiers, matching the defensive pattern in AreVersionsChanged, UpdateChromeVersionsFile, and UpdateEnvVarsForPRFile.

✅ Fallback Logic — correct behavior

When the CDN check fails, the fallback correctly:

1. Re-reads ChromeVersionsPath from disk (safe because each OS's V8 version node is independent)
2. Uses the existing V8 version in the ChromeVersionSpec, so UpdateChromeVersionsFile writes the old V8 version back while still updating Chrome version, revision, and snapshot URL
3. Emits a LogWarning so the outcome is visible in build logs

✅ BrowserVersions.props — changes are consistent

• Linux Chrome bumped: 146.0.7680.80 → 147.0.7727.55 ✅
• Linux V8 kept at 14.6.202 (reverted from 14.7.173 because binary unavailable on CDN) ✅
• Windows V8 at 14.7.173 (not reverted, presumably available for win32) ✅

💡 TaskCanceledException not caught in IsV8BinaryAvailableAsync

HttpClient.SendAsync can throw TaskCanceledException on timeout (default 100s), which would propagate up and fail the build task instead of gracefully falling back. Only HttpRequestException is caught. This is consistent with the existing GetDownloadFileStreamAsync pattern in the same file, so not blocking — but catching TaskCanceledException as well and returning false would make the fallback more resilient to transient network slowness.

Generated by Copilot code review

Generated by Code Review for issue #126802 · ◷