Skip to content

Further attempt to fix CancelsOutdatedRefreshes_Async in CI #32998

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 25, 2021

Conversation

SteveSandersonMS
Copy link
Member

@SteveSandersonMS SteveSandersonMS commented May 25, 2021

The previous attempt to fix this in #32869 actually made it worse. It went from being flaky in CI to failing 100% of the time in CI, even though it passes 100% of the time locally.

The implementation here is just a manual equivalent to the behavior: 'smooth' flag to see if that works better.

Sidenote: I'm increasingly thinking it may be a more fundamental aspect of the CI environment that makes anything based on human timescales for interactivity (which UI tests should and must be) unviable. Browsers aren't designed to operate in conditions where they're unable to execute code in response to events because of excessive resource contention. If that is the case we're going to have to set up a separate, dedicated environment for running E2E tests that is not in contention for resources with other build or test activities, or at least have a more sophisticated mechanism for retries. If the Playwright efforts prove this wrong then of course that would be better still, but as yet we haven't got there.

@SteveSandersonMS SteveSandersonMS requested a review from a team as a code owner May 25, 2021 14:11
@ghost ghost added the area-blazor Includes: Blazor, Razor Components label May 25, 2021
for (var y = 1000; y <= 5000; y += 1000)
{
js.ExecuteScript($"document.getElementById('async-container').scrollTo({{ top: {y} }})");
Browser.Equal(y, () => (long)js.ExecuteScript("return document.getElementById('async-container').scrollTop"));
Copy link
Member Author

Choose a reason for hiding this comment

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

This line is just about waiting until we can observe the browser did what we asked.

@HaoK
Copy link
Member

HaoK commented May 25, 2021

@SteveSandersonMS if you want, you can try also your fix with a PR against the current playwright PR (https://github.com/dotnet/aspnetcore/tree/haok/pw3) and add this test there to see if it helps (I believe there are many issues that are alleviated due to playwright running on helix machines without resource contention)? I'd also love for you to try things for more feedback/suggestions in case anything feels off during the conversion:

Here's a similar test that does an evaluate:

var base64 = await TestPage.EvaluateAsync<string>($@"

@SteveSandersonMS SteveSandersonMS merged commit 89889e7 into main May 25, 2021
@SteveSandersonMS SteveSandersonMS deleted the stevesa/fix-virtualization-cancellation-test branch May 25, 2021 16:21
@ghost ghost added this to the 6.0-preview6 milestone May 25, 2021
@SteveSandersonMS
Copy link
Member Author

@HaoK Thanks for the info. Since this has passed now I'm keen to get it in as-is. We can certainly consider migrating this test to Playwright if it continues to see issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants