Skip to content

Skip flaky/broken tests on release/10.0.4xx - #54277

Closed
marcpopMSFT wants to merge 1 commit into
release/10.0.4xxfrom
fix/skip-flaky-tests-10.0.4xx
Closed

marcpopMSFT wants to merge 1 commit into
release/10.0.4xxfrom
fix/skip-flaky-tests-10.0.4xx

Conversation

@marcpopMSFT

Copy link
Copy Markdown
Member

Summary

Skips two test failures that are causing noise on release/10.0.4xx CI builds (e.g., PR #54267 build 1417760).

1. \AllWebProjectsRestoreAndBuild(mvc_fs-90)\ — TemplateEngine (all platforms)

The F# MVC template targeting net9.0 includes an explicit dependency on \Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation >= 9.0.16. This package version is not yet available on the CI's Azure DevOps NuGet feeds, causing \NU1202\ restore failures. NuGet resolves to the 10.0.0 version instead, which is incompatible with net9.0.

Fix: Extracted the \mvc_fs-90\ InlineData case into a separate [Fact(Skip = ...)]\ method referencing #40073.

2. \StaticWebAssets_BackCompatibilityPublish_Hosted_Works\ — FullFramework (Windows)

Known flaky file lock on .gz\ compression temp files in the legacy .NET 5 back-compat publish path (\BlazorWebAssembly.5_0.targets\ line 650). Already tracked as a Known Build Error.

Fix: Added \Skip\ attribute referencing #53660.

Neither failure is related to any code changes — they are pre-existing test infrastructure issues.

Copilot AI review requested due to automatic review settings May 13, 2026 00:03
@marcpopMSFT
marcpopMSFT requested review from a team as code owners May 13, 2026 00:03

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Skips two known failing/flaky tests on release/10.0.4xx to reduce CI noise, aligning the skips with tracked GitHub issues.

Changes:

  • Skip StaticWebAssets_BackCompatibilityPublish_Hosted_Works due to a known flaky file lock issue (#53660).
  • Move the mvc_fs-90 case out of AllWebProjectsRestoreAndBuild and into its own skipped test referencing #40073.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File Description
test/Microsoft.NET.Sdk.BlazorWebAssembly.Tests/BlazorWasmStaticWebAssetsIntegrationTest.cs Adds a skip to a flaky back-compat publish test.
test/dotnet-new.IntegrationTests/WebProjectsTests.cs Extracts the F# MVC net9.0 test case and skips it behind a tracked issue.

Comment thread test/dotnet-new.IntegrationTests/WebProjectsTests.cs
@marcpopMSFT
marcpopMSFT force-pushed the fix/skip-flaky-tests-10.0.4xx branch from 665752b to 40c12ae Compare May 13, 2026 17:06
@marcpopMSFT
marcpopMSFT requested a review from MichaelSimons May 13, 2026 18:01
@marcpopMSFT

Copy link
Copy Markdown
Member Author

This is copilots attempt at a fix for the issues I ran into in #54267 that should not impact our tests. For the gzip one, it's a retry as the file was locked. It's a bit hacky and it's in product code so I'm open to alternatives.

For the templating change, it suggested we'd need to modify on the templating side so I figure we'd disable here and fix in main as downlevel fsharp mvc templating coverage may be ok to miss from 10 servicing.

Comment thread src/BlazorWasmSdk/Tasks/GZipCompress.cs
- Skip AllWebProjectsRestoreAndBuild for F# MVC net9.0 (mvc_fs-90):
  The F# MVC template includes Microsoft.AspNetCore.Mvc.Razor.RuntimeCompilation
  which at version 9.0.16 may not be available on CI NuGet feeds yet,
  causing NU1202 restore failures. See #40073.

- Fix GZipCompress file lock flakiness (#53660):
  Add retry logic (3 retries with backoff) to GZipCompress.Execute()
  for IOException during file I/O. The legacy .NET 5 back-compat
  Blazor publish path compresses files in parallel and can hit
  transient file locks from antivirus or parallel test execution.
  Follows the same pattern as GenerateBundle.cs.

- Revert test skip on StaticWebAssets_BackCompatibilityPublish_Hosted_Works
  since the root cause (GZipCompress) is now fixed.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@marcpopMSFT
marcpopMSFT force-pushed the fix/skip-flaky-tests-10.0.4xx branch from 6eb3fcb to 4c2618b Compare May 13, 2026 23:13
@marcpopMSFT
marcpopMSFT requested a review from MichaelSimons May 15, 2026 22:10
@marcpopMSFT

Copy link
Copy Markdown
Member Author

@MichaelSimons thoughts on the whether we should take the gzip retry loop to improve test quality (and presumably product quality)?

@MichaelSimons

Copy link
Copy Markdown
Member

@MichaelSimons thoughts on the whether we should take the gzip retry loop to improve test quality (and presumably product quality)?

You are asking if we should backport the fix that already went into main. Looking at the recent occurrences of #53660, they all appear in 10.0.4xx not main. That presumably means the fix in main is working. If that is the case, I think it is reasonable to backport. This would require tactics approval right? Perhaps a good reason to split the two changes in this PR apart.

@marcpopMSFT

Copy link
Copy Markdown
Member Author

@MichaelSimons thoughts on the whether we should take the gzip retry loop to improve test quality (and presumably product quality)?

You are asking if we should backport the fix that already went into main. Looking at the recent occurrences of #53660, they all appear in 10.0.4xx not main. That presumably means the fix in main is working. If that is the case, I think it is reasonable to backport. This would require tactics approval right? Perhaps a good reason to split the two changes in this PR apart.

@MichaelSimons I hadn't even noticed that the gzip task had already been fixed with a similar change in main. We should definitely not take this PR then as there will be merge conflicts.

So the question is, is everything from #53424 worth bringing into 4xx or just the gzip change or some subset? No tactics is needed for 4xx. We'd have to decide on 1xx as that would require tactics and be riskier.

@marcpopMSFT

Copy link
Copy Markdown
Member Author

I went ahead and asked copilot to take a look at that other PR from Matt and determine what we should back port to 4xx and I'll have it create a PR. We can proceed with that as it should not have the merge conflicts this PR would have.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants