[ci-fix] De-flake DispatcherTests by serializing DispatcherProvider global-state mutators

[github-actions]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Target branch: main
Refs: #35910
Attempt: 1/10
Outcome: de-flake (test-quality flake — genuine state-leakage/ordering defect in the test, not a product bug and not infra)

Summary

Microsoft.Maui.UnitTests.Dispatching.DispatcherTests.CreateTimerNonRepeatingDoesNotRepeat intermittently fails on the main maui-pr pipeline with a NullReferenceException (seen in build 1459938, Helix queue osx.15.arm64.maui.open, work item Microsoft.Maui.UnitTests.dll). It is a test-quality flake caused by two test classes racing on a process-global static — not a product defect — so it is de-flaked rather than muted.

Root cause

The reported stack trace points at DispatcherTests.cs line 140, which is var timer = dispatcher.CreateTimer(); — i.e. dispatcher is null, so Dispatcher.GetForCurrentThread() returned null a few lines earlier:

DispatcherTest.Run(async () =>
{
    var dispatcher = Dispatcher.GetForCurrentThread();   // returns null under the race
    var ticks = 0;
    var timer = dispatcher.CreateTimer();                // line 140 -> NullReferenceException
    ...
    await Task.Delay(TimeSpan.FromSeconds(1.1));          // the FIRST await is here, AFTER the NRE
});

DispatcherTest.Run executes the test body on a fresh dedicated new Thread(...), and the failing line runs synchronously, before the first await. On a brand-new thread every [ThreadStatic] starts at its default, so a leaked DispatcherProviderStubOptions.SkipDispatcherCreation flag cannot be the cause of this failure.

The real cause is a data race on the process-global provider in src/Core/src/Dispatching/DispatcherProvider.cs:

static IDispatcherProvider? s_currentProvider;                    // process-global, not thread-static
public static IDispatcherProvider Current => s_currentProvider ??= new DispatcherProvider();

DispatcherTests (ctor SetCurrent(stub), Dispose SetCurrent(null)) and MainThreadBridgeTests (repeatedly SetCurrent(stub) / SetCurrent(null)) are the only two classes in this assembly that mutate that global, and by default xUnit runs different test classes in parallel collections. When MainThreadBridgeTests calls DispatcherProvider.SetCurrent(null) at the moment DispatcherTests' dedicated thread reads DispatcherProvider.Current, the getter lazily constructs the real DispatcherProvider, whose GetForCurrentThreadImplementation() returns null on a non-UI thread → null dispatcher → NullReferenceException. Whether the two interleave is timing-dependent, which is why it reproduces ~1 in 10 builds and passes on retry.

Fix

Introduce a shared, non-parallel xUnit collection and apply it to the only two classes that touch the global, so they can never run concurrently:

[CollectionDefinition(DispatcherProviderGlobalStateCollection.Name, DisableParallelization = true)]
public class DispatcherProviderGlobalStateCollection
{
    public const string Name = "DispatcherProviderGlobalState";
}

[Category(TestCategory.Core, TestCategory.Dispatching)]
[Collection(DispatcherProviderGlobalStateCollection.Name)]
public class DispatcherTests : IDisposable { ... }

[Category(TestCategory.Core, TestCategory.Hosting)]
[Collection(DispatcherProviderGlobalStateCollection.Name)]
public class MainThreadBridgeTests : IDisposable { ... }

This mirrors the existing in-repo pattern CultureTestsCollection (src/Controls/tests/SourceGen.UnitTests). No assertion is removed or weakened, no test is disabled or skipped, no [Retry]/[Repeat] is added, and no timeout is changed — the two racing classes are simply serialized. This is a deterministic state-leakage de-flake, not a mute.

Relationship to net11.0 PR #36221

The parallel net11.0 workflow opened #36221 for the same test file, fixing a different latent flake: a [ThreadStatic] SkipDispatcherCreation leak from BackgroundThreadDoesNotGetDispatcherFromMainThread onto a pooled thread, observable only in an async continuation after an await. That mechanism cannot explain #35910's signature, which fails before any await on a fresh non-pooled thread. The two fixes are complementary and non-overlapping; this PR targets main and the SetCurrent race specifically.

Validation

• Static root-cause: the null dispatcher can only originate from a concurrent SetCurrent(null) on the shared global; serializing the two — and only two — mutator classes in this assembly removes the concurrency window at its source.
• Not runner-validated locally: the agent sandbox is network-restricted (the Arcade SDK feed returns proxy 403), so the repo cannot be restored/built here, and the failure is a low-frequency race that cannot be reproduced on demand. This PR's own maui-pr CI — specifically the Helix Unit Tests legs that execute Microsoft.Maui.UnitTests.dll — exercises the change.

_{Automated CI-fix candidate (main). Draft for human review — please verify before merging.}

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• l49vsblobprodcus358.vsblob.vsassets.io

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "l49vsblobprodcus358.vsblob.vsassets.io"

See Network Configuration for more information.

Generated by CI Failure Fixer (main) · 3.7K AIC · ⌖ 106.9 AIC · ⊞ 79.2K · ◷

[PureWeen]

Closing as a duplicate canary artifact. This draft was auto-generated by a live test dispatch of the CI-fix workflow (#36317) running from a feature branch, not a scheduled run. It is a byte-identical duplicate of its sibling (the two were created by a single agent cycle that incorrectly re-emitted create_pull_request to 'overwrite' an oversized patch — the safe-output handler mints a new branch + PR per emission, so it duplicated instead). It also overlaps the existing de-flake in #36221 (same DispatcherTests flake, issue #36192). Being cleaned up; the underlying prompt bug is being fixed in #36317.