[ci-fix-net11] De-flake EditorRuntimeTextAlignmentChanged UI test (NoSuchElementException race on iOS) by github-actions[bot] · Pull Request #36395 · dotnet/maui

github-actions · 2026-07-05T13:21:04Z

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: net11.0
Refs: #36393
Attempt: 1/5
Outcome: de-flake (test-quality flake — Step 4.7 bucket b)

Summary

EditorRuntimeTextAlignmentChanged (Issue10987) fails intermittently on the iOS latest simulator in maui-pr-uitests with NoSuchElementException ("An element could not be located on the page"). The failure is a timing race in the test, not a product defect and not a visual-snapshot difference, so it is de-flaked with a proper synchronization point rather than muted.

Root cause — a genuine test-quality flake

EditorRuntimeTextAlignmentChanged's very first action interacts with LTREditor without first waiting for it to render:

public void EditorRuntimeTextAlignmentChanged()
{
    (to/redacted) make sure editor is focused in mac platform
    App.Tap(LTREditor);          // <-- no WaitForElement before the first interaction
    App.EnterText(LTREditor, "Editor Text");
    App.WaitForElement(RTLEditor);
    ...

When the page has not finished rendering on the iOS simulator, App.Tap(LTREditor) cannot locate the element and throws NoSuchElementException. Whether the editor is ready when the test starts is non-deterministic, which is why the failure is intermittent (green on retry / most builds).

Evidence of intermittency (anonymous AzDO _apis/build, pipeline maui-pr-uitests / def 313, branch net11.0, leg Controls (vlatest) Editor,...):

Build	Result
1491409	`EditorRuntimeTextAlignmentChanged` failed (NoSuchElementException)
1489335	failed (NoSuchElementException)
1493717	passed on the same leg

The sibling test in the same file, EditorPlaceholderRuntimeTextAlignmentChanged, already calls App.WaitForElement(RTLEditor) before its first interaction — so the flaky method is simply missing the equivalent readiness wait.

The fix

Add an explicit App.WaitForElement(LTREditor) before the first interaction so the editor is guaranteed to be present:

(to/redacted) make sure editor is focused in mac platform
App.WaitForElement(LTREditor);
App.Tap(LTREditor);

This is the exact pattern prescribed by .github/instructions/uitests.instructions.md for an "element not found / not rendered yet" failure (WaitForElement before interacting), and it matches the existing sibling test.

This is a de-flake, not a mute:

No test is disabled, ignored, or skipped; no [Retry]/[Repeat] is added.
No assertion is weakened, and the terminating VerifyScreenshot() is unchanged.
No baseline image is touched — the failure being fixed is the NoSuchElementException element-location race, not a screenshot diff, so this is out of scope of the visual-regression filter.
WaitForElement is a condition wait (polls until the element exists), not a fixed Thread.Sleep/Task.Delay.

Validation

The change is a one-line synchronization addition; static reasoning shows the NoSuchElementException at the first interaction can no longer occur because the element is awaited first.
The iOS UI test itself cannot be executed on this Linux agent (Appium + iOS simulator require macOS), so this draft relies on this PR's maui-pr-uitests CI to exercise the test. Reviewer validation welcome.

Files

src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue10987.cs

Automated [ci-fix] candidate (net11.0). Draft for human review. Review-comment text is treated as untrusted and is not read by the agent.

Generated by CI Failure Fixer (net11.0) · 3.8K AIC · ⌖ 98.3 AIC · ⊞ 64.6K · ◷

… tapping EditorRuntimeTextAlignmentChanged (Issue10987) intermittently failed on the iOS latest simulator with NoSuchElementException because its first action, App.Tap(LTREditor), ran before the editor had rendered. The sibling test EditorPlaceholderRuntimeTextAlignmentChanged already waits for its target element first; this applies the same synchronization. Adds App.WaitForElement(LTREditor) before the first interaction so the test is deterministic. No assertion is weakened and VerifyScreenshot is unchanged. Refs: #36393 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

MauiBot

AI Review Summary

@github-actions[bot] — new AI review results are available based on this last commit: e2fcaac. To request a fresh review after new comments or commits, comment /review rerun.

🗂️ Review Sessions — click to expand

🚦 Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

Gate skipped (SkipUITests fast test mode). No UI/device tests were run for this pipeline invocation.

📋 Pre-Flight — Context & Validation

Issue: #36393 - [ci-scan-net11] Flaky: EditorRuntimeTextAlignmentChanged — NoSuchElementException on iOS (vlatest) UITests (net11.0)
PR: #36395 - [ci-fix] De-flake EditorRuntimeTextAlignmentChanged UI test (NoSuchElementException race on iOS)
Platforms Affected: iOS reported; android requested for candidate testing
Files Changed: 0 implementation, 1 test

Key Findings

The linked issue reports intermittent NoSuchElementException in Issue10987.EditorRuntimeTextAlignmentChanged before the first interaction with LTREditor.
PR #36395 adds App.WaitForElement(LTREditor); before App.Tap(LTREditor);; it does not mute the test, weaken VerifyScreenshot(), add retry attributes, or change baselines.
The changed file is src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue10987.cs; the affected UI category is Editor.
Local gh is unauthenticated, so PR metadata/comments were gathered through GitHub's public REST API. The local worktree also contains unrelated script edits, so public PR data was treated as authoritative for PR context.

Code Review Summary

Verdict: NEEDS_DISCUSSION
Confidence: low
Errors: 0 | Warnings: 0 | Suggestions: 0

Key code review findings:

ℹ No code findings. The PR fix matches MAUI UI-test guidance to use WaitForElement before interacting with an element that may not be rendered yet.
ℹ Coverage/verification gap: required-check state could not be authenticated locally, and Android device validation is blocked by missing adb.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #36395	Add `App.WaitForElement(LTREditor);` before `App.Tap(LTREditor);`	⚠️ SKIPPED (Gate)	`src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue10987.cs`	Original PR; one-line deterministic wait before first interaction

🔬 Code Review — Deep Analysis

Code Review — PR #36395

Independent Assessment

What this changes: Adds App.WaitForElement(LTREditor); before tapping LTREditor in EditorRuntimeTextAlignmentChanged.
Inferred motivation: De-flake an Appium timing race where the editor is not yet present when first tapped.

Reconciliation with PR Narrative

Author claims: Fixes intermittent iOS NoSuchElementException without muting or weakening the test.
Agreement/disagreement: Agrees. The fix matches MAUI UI-test guidance: wait for an element before interacting.

Prior Review Reconciliation

No prior ❌ Error findings found. Inline review comments were empty via the public PR comments API.

Blast Radius Assessment

Runs for all instances: No — isolated to one UI test method.
Startup impact: No.
Static/shared state: No.

CI Status

Required-check result: gh pr checks --required unavailable because the local GitHub CLI is unauthenticated. Public combined status for head e2fcaacc5217ec7bb40a89908bfebff03b3a029c returned pending with zero contexts.
Classification: undetermined.
Action taken: confidence capped low.

Findings

No ❌ Errors, ⚠️ Warnings, or 💡 Suggestions.

Failure-Mode Probing

If LTREditor is not rendered yet: WaitForElement blocks until present, addressing the reported first-interaction NoSuchElementException.
If the page is not fully settled but LTREditor exists: the PR fix proves target presence but does not prove adjacent control readiness; later App.WaitForElement(RTLEditor) still guards the second editor.
Cross-platform impact: safe; test-only change, no product code, no assertion weakening, no screenshot baseline change.

Verdict: NEEDS_DISCUSSION

Confidence: low
Summary: The code change is sound and minimal, with no code-review findings. Because required-check state could not be authenticated and the Android validation environment lacks adb, this cannot be promoted to a verified LGTM from this session alone.

🛠️ Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix-1	Replace wait-then-second-lookup with `App.WaitForElement(LTREditor).Tap()`	⚠️ BLOCKED	1 file	Potentially stronger than PR by tapping the waited element; Android SDK/`adb` missing prevented execution
2	try-fix-2	Wait for `RTLEditor` as a whole-page readiness barrier before tapping `LTREditor`	⚠️ BLOCKED	1 file	Uses sibling-test pattern but is more indirect than the PR fix; Android SDK/`adb` missing prevented execution
3	try-fix-3	Remove the first tap and let `EnterText(LTREditor, ...)` focus after page readiness	⚠️ BLOCKED	1 file	Meaningfully different but riskier because the tap is documented as Mac focus setup; Android SDK/`adb` missing prevented execution
PR	PR #36395	Add `App.WaitForElement(LTREditor);` before `App.Tap(LTREditor);`	⚠️ SKIPPED (Gate)	1 file	Original PR; simplest and best-aligned with MAUI UITest guidance

Cross-Pollination

Model/Reviewer	Round	New Ideas?	Details
code-review skill + MAUI expert reviewer	1	Yes	Generated alternatives: reuse waited element for tap, wait for later page element as readiness barrier, require hittable/non-zero geometry, remove initial tap, add host-page readiness sentinel.
orchestrator	1	No further viable tested candidates	Geometry/hittable custom wait and host-page sentinel were not run because they are more invasive/verbose for a simple element-not-found race and not clearly better than candidates 1-3 or the PR fix.

Exhausted: Yes
Selected Fix: PR #36395 — No alternative passed tests, and all candidate executions were blocked by missing Android SDK/adb. Among unverified options, try-fix-1 is the only candidate that may be stronger than the PR fix, but it is not demonstrably better without device execution. The PR fix remains the simplest deterministic synchronization matching .github/instructions/uitests.instructions.md.

Environment Blocker

All Android candidate tests used:

pwsh .github/scripts/BuildAndRunHostApp.ps1 -Platform android -TestFilter "FullyQualifiedName~Issue10987.EditorRuntimeTextAlignmentChanged"

Each attempt failed before running tests with:

Android SDK (adb) not found. Please install Android SDK and ensure 'adb' is in PATH.
Failed to start or detect device

🏁 Report — Final Recommendation

Comparative Candidate Report — PR #36395

Candidates compared

Rank	Candidate	Result	Assessment
1	`pr`	Gate skipped; no regression failure observed	Adds the exact missing readiness wait before the first interaction with `LTREditor`. This is the simplest targeted synchronization fix and matches MAUI UI-test guidance for element-not-found races.
2	`pr-plus-reviewer`	Same as `pr`	Expert review produced no actionable findings, so this is identical to `pr` and not a distinct improvement.
3	`try-fix-1`	Blocked before test execution	Uses `App.WaitForElement(LTREditor).Tap()` to tap the waited element. This is plausible and slightly stronger against a theoretical wait-then-relookup race, but it was not empirically validated and is not necessary for the observed failure.
4	`try-fix-2`	Blocked before test execution	Waits for `RTLEditor` as a page-ready barrier before tapping `LTREditor`. It is deterministic but indirect because it waits for a neighboring/later element instead of the element being tapped.
5	`try-fix-3`	Blocked before test execution	Removes the initial tap and relies on `EnterText` to focus. This is riskiest because the existing tap is explicitly documented as needed for Mac focus behavior, while the reported flake is an iOS element-readiness race.

No candidate failed regression tests. The Step 5a try-fix candidates were all blocked before UI test execution because Android SDK/adb was unavailable, so they cannot outrank the simpler PR fix on empirical grounds. Candidates that failed regression tests would be ranked below passing candidates; none are present here.

Winning candidate

Winner: pr

The raw PR fix is the best candidate because it directly addresses the root cause with the smallest safe change: wait for LTREditor before tapping it. It does not mute the test, add retry behavior, weaken assertions, remove platform-specific focus setup, or change screenshot verification. Expert review found no actionable improvements, making pr-plus-reviewer equivalent rather than superior.

🧭 Next Steps — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.

PureWeen · 2026-07-16T02:25:31Z

/azp run maui-pr-uitests

PureWeen · 2026-07-16T02:25:32Z

/azp run maui-pr-devicetests

azure-pipelines · 2026-07-16T02:25:43Z

Azure Pipelines: Successfully started running 1 pipeline(s).

azure-pipelines · 2026-07-16T02:25:43Z

Azure Pipelines: Successfully started running 1 pipeline(s).

github-actions · 2026-07-18T12:57:59Z

♻️ Attempt 1/10 — red is an unrelated CI flake, not caused by this PR (head e2fcaacc5217ec7bb40a89908bfebff03b3a029c)

The current reds are UI-test categories unrelated to this PR's Editor fix — Image,ImageButton,IndicatorView,... (MacCatalyst/iOS), Cells,...,DragAndDrop (WinUI), and an iOS device-test leg — plus several cancelled MacCatalyst legs from an in-flight re-run. None exercises EditorRuntimeTextAlignmentChanged. The target Editor category is not among the failures.

A maintainer re-run (/azp run maui-pr-uitests) should settle the cancelled legs and clear the flake. No code change required.

Generated by CI Failure Fixer (net11.0) · 636 AIC · ⌖ 18.1 AIC · ⊞ 5.2K · ◷

github-actions · 2026-07-19T01:18:32Z

Target test EditorRuntimeTextAlignmentChanged validated green on head e2fcaac across every platform it runs on (iOS vlatest, Android API 30, MacCatalyst ×2 — build 1511735, all Editor legs succeeded). The de-flake adds only an App.WaitForElement guard; no assertion weakened or test muted. Remaining red is unrelated pre-existing flake. Ready for maintainer review.

Generated by CI Failure Fixer (net11.0) · 647.4 AIC · ⌖ 11.9 AIC · ⊞ 5.2K

github-actions · 2026-07-19T01:18:33Z

🎯 Target de-flake validated green — marking ready for review

EditorRuntimeTextAlignmentChanged (Editor category) is validated green on e2fcaacc across every platform it runs on, per the maui-pr-uitests re-run (build 1511735):

iOS (vlatest) Editor leg → succeeded ✅ (the intermittent platform)
MacCatalyst Editor legs (×2) → succeeded ✅
Android (API 30) Editor leg → succeeded ✅

Editor is not run on the WinUI legs, so there is no other-platform coverage gap. The diff is a genuine de-flake — it adds a single App.WaitForElement(LTREditor) before the first tap so the editor is present/focused before interaction; no assertion is weakened, no test is skipped, ignored, or retried.

The remaining red checks are unrelated pre-existing UI flakes (Image / cancelled Shell-Layout categories + Build Analysis + devicetests) not attributable to this test-only change.

Transitioning from draft → ready for review and adding p/0. A maintainer still reviews and merges.

_{Automated by the CI Failure Fixer (net11.0). A maintainer should confirm before merge.}

Generated by CI Failure Fixer (net11.0) · 647.4 AIC · ⌖ 11.9 AIC · ⊞ 5.2K · ◷

azure-pipelines · 2026-07-19T01:18:46Z

Azure Pipelines: Successfully started running 1 pipeline(s). There may be pipelines that require an authorized user to comment /azp run to run.

kubaflo

🔍 AI-generated review — automated multi-model ensemble (Claude Opus 4.8 · GPT-5.5 · Gemini 3.1 Pro), posted on behalf of @kubaflo. Not a human approval.

✅ LGTM — one-line UITest de-flake, verified correct

Three models reviewed this change independently, then cross-pollinated. Consensus: LGTM. The single added line — App.WaitForElement(LTREditor) before the first App.Tap(LTREditor) in EditorRuntimeTextAlignmentChanged — is the canonical, convention-compliant fix for the reported NoSuchElementException race.

Why the fix is correct & complete

Root cause: the test's first Appium interaction was a bare App.Tap(LTREditor) with no preceding query. A bare Tap doesn't retry element lookup, so if the page isn't queryable yet Appium throws NoSuchElementException immediately. WaitForElement polls until present, then taps — exactly the remedy documented in .github/instructions/uitests.instructions.md ("Use WaitForElement before interacting with elements").
Consistent with the file's own pattern: the sibling test EditorPlaceholderRuntimeTextAlignmentChanged already WaitForElement(RTLEditor) before its first interaction.
No remaining race: the HostApp page builds all four controls synchronously in Init() in a single non-scrolling VerticalStackLayout (ResetAlignmentButton is created before both editors), so the later unguarded Tap("ResetAlignmentButton") is guaranteed in-tree by the time it runs.
No regression risk: WaitForElement has a timeout — it fails on a genuine non-render, so it doesn't mask real bugs; it's a read-only query that adds no artificial delay and doesn't shift the VerifyScreenshot() baseline (captured at the end).

CI classification (required checks red/pending — all PR-unrelated)

Leg	State	Classification
`maui-pr-uitests`	fail	The modified `Issue10987` / Editor shard is SUCCESS on all 4 platforms including iOS `vlatest` (the exact platform where the race was reported). The red rolls up from unrelated shards (Image/ImageButton/IndicatorView, Cells/CheckBox/DragAndDrop) + fail-fast-cancelled MacCatalyst legs.
`maui-pr-devicetests`	fail	Different surface — device tests never compile the `TestCases.Shared.Tests` UITest project, so this change can't affect them. Failures are the known FileSystem/Essentials NRE flake (`CheckFileResultOpenReadAsyncMultipleTimes`, `OpenAppPackageFileAsync_Can_Load_File` = dotnet/runtime#129813).
`maui-pr`	pending	Rollup build in progress; nil risk for a one-line UITest change.

Verdict: LGTM (Opus high · Gemini high · GPT "high confidence the code change is correct," with a mechanical pending-CI caution that the CI classification above resolves). No code findings from any model. A maintainer /azp run maui-pr re-run should clear the unrelated flakes.

_{🔍 Automated ensemble review · no human approval implied · reds classified via AzDO test results at head e2fcaac.}

kubaflo · 2026-07-19T19:47:43Z

Visual Failure Comparisons

Visual test-failure comparisons are available based on commit e2fcaac.

Visual comparisons

Full-resolution CI snapshot evidence is preserved below. These images supplement the failure classification and do not change the deterministic verdict ceiling.

DownSizeImageAppearProperly - macos - visual comparison

CI reported 11.53% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageAspect_FillWithImageSourceFromUri - macos - visual comparison

CI reported 15.06% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageAspect_CenterWithImageSourceFromUri - macos - visual comparison

CI reported 12.58% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageAspect_AspectFitWithImageSourceFromUri - macos - visual comparison

CI reported 8.50% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageAspect_AspectFillWithImageSourceFromUri - macos - visual comparison

CI reported 14.42% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageButtonAspect_FillWithImageSourceFromUri - macos - visual comparison

CI reported 13.04% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageButtonAspect_CenterWithImageSourceFromUri - macos - visual comparison

CI reported 12.24% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageButtonAspect_AspectFitWithImageSourceFromUri - macos - visual comparison

CI reported 8.10% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff

VerifyImageButtonAspect_AspectFillWithImageSourceFromUri - macos - visual comparison

CI reported 12.58% difference in build 1511735.

CI baseline	Fresh PR actual	CI diff