Fix SuppliesCancellationTokenThatSignalsWhenRevalidationLoopIsBeingDiscarded flake

[oroztocil]

Fixes and unquarantines Microsoft.AspNetCore.Components.RevalidatingServerAuthenticationStateProviderTest.SuppliesCancellationTokenThatSignalsWhenRevalidationLoopIsBeingDiscarded.

The test was flaky because the loop in RevalidatingServerAuthenticationStateProvider.RevalidationLoop can do multiple iterations between the relevant lines of the test. This means that ValidateAuthenticationStateAsync is (successfully) fired multiple times and logs more than one (identical) logs. If I understand the context correctly, this is a legitimate outcome and the assertion should not check for strict log collection equivalnce, only that the remaining logs in the collection are as expected.

When runnning the test locally with the revalidation interval set to 3ms instead of 50ms, I got ~1/400 failed runs. With the change, no runs failed after 3000+ executions.

Alternatively, the TestRevalidatingServerAuthenticationStateProvider class could be rewritten to allow stricter dependable assertions. However, this solution seems cost-efficient.

Fixes #60472

[Copilot]

Pull Request Overview

This PR fixes a flaky test by addressing timing issues in the revalidation loop. The test SuppliesCancellationTokenThatSignalsWhenRevalidationLoopIsBeingDiscarded was intermittently failing because the revalidation loop could execute multiple iterations between test assertions, causing more log entries than expected.

• Removes the quarantine attribute from the flaky test
• Changes assertion from Assert.Collection to Assert.All to handle variable number of log entries
• Adds explanatory comments about the timing behavior

[oroztocil]

See the relevant RevalidationLoop code:

aspnetcore/src/Components/Server/src/Circuits/RevalidatingServerAuthenticationStateProvider.cs

Line 73 in 5afdc06

isValid = await ValidateAuthenticationStateAsync(authenticationState, cancellationToken);

And the test implementation of the abstract method called per loop iteration (until the revalidation is cancelled, or until it fails and causes a logout):

aspnetcore/src/Components/Server/test/Circuits/RevalidatingServerAuthenticationStateProviderTest.cs

Line 248 in 5afdc06

protected override Task<bool> ValidateAuthenticationStateAsync(AuthenticationState authenticationState, CancellationToken cancellationToken)

To avoid confusion, it is correct that the revalidation loop (possibly) runs multiple iterations of ValidateAuthenticationStateAsync. It is the responsibility of the implementers of RevalidatingServerAuthenticationStateProvider that they deal with this fact properly. Our test implementation is not idempotent (with regards to repeated successful auth state validations) - which means that we either need to account for that in our test assertions (change in this PR) or change the test implementation.

[ilonatommy]

Looking at the RevalidationLoop logic, the reasoning looks valid.

[javiercn]

/backport to release/10.0

[github-actions]

Started backporting to release/10.0: https://github.com/dotnet/aspnetcore/actions/runs/17460064736