Flaky: MenuBarTests.ChangesKey_RaisesEvent NRE in AppTestHelper.Stop/WaitIteration during teardown (macOS) #5585

Observed

IntegrationTests.MenuBarTests.ChangesKey_RaisesEvent(d: "dotnet") failed once on Integration Tests (macos-latest) for release PR #5584, then passed on rerun with identical code (and had passed on #5583 minutes earlier).

Failed job: https://github.com/tui-cs/Terminal.Gui/actions/runs/28839360411/job/85529921078

System.NullReferenceException : Object reference not set to an instance of an object.
   at AppTestHelpers.AppTestHelper.WaitIteration(Action`1 action) in Tests/AppTestHelpers/AppTestHelper.cs:358
   at AppTestHelpers.AppTestHelper.Stop() in Tests/AppTestHelpers/AppTestHelper.cs:480
   at AppTestHelpers.AppTestHelper.Dispose() in Tests/AppTestHelpers/AppTestHelper.cs:587
   at IntegrationTests.MenuBarTests.ChangesKey_RaisesEvent(String d) in Tests/IntegrationTests/FluentTests/MenuBarTests.cs:119

Likely cause

AppTestHelper.WaitIteration (AppTestHelper.cs:358) builds its wait-handle array with a null-forgiving dereference:

WaitHandle [] waitHandles =
[
    _runCancellationTokenSource.Token.WaitHandle,
    ctsActionCompleted.Token.WaitHandle,
    _ansiInput.ExternalCancellationTokenSource!.Token.WaitHandle
];

When Dispose → Stop → WaitIteration runs while the app is already shutting down, _ansiInput.ExternalCancellationTokenSource (or the input object's state) can be nulled/disposed concurrently, so the ! dereference throws NRE. Teardown race in test infrastructure — not a product bug.

Suggested fix

In WaitIteration (and Stop), snapshot ExternalCancellationTokenSource into a local and skip/guard the handle when it is null (or already disposed), rather than using !.

Filed while shepherding release v2.4.17 (#5584); the failure was cleared by a rerun.

🤖 Generated with Claude Code