Summary
Interactive_DataGrid_RowEditTab_DoesNotSuppressNextCommit intermittently fails in the E2E Tests (winapp ui) job with:
Assertion failed. Expected value to not be null.
Row edit did not start — no 'Save' button appeared.
actual: null
Assert.IsNotNull(WaitForName("Save"))
at DataGridTests.BeginRowEditOnFirstRow() in tests/Reactor.AppTests/Tests/DataGridTests.cs:399
at DataGridTests.Interactive_DataGrid_RowEditTab_DoesNotSuppressNextCommit() in tests/Reactor.AppTests/Tests/DataGridTests.cs:312
This is flake, not a regression — proven by same-SHA disagreement
Two commits on main have both passed and failed the E2E job at the identical SHA, which rules out any code change as the cause:
| SHA |
Date |
E2E result |
0a04370c |
2026-09-25 |
success |
8cc49cea |
2026-09-25 |
success |
c767c0fd |
2026-09-25 |
success |
a58008a1 |
2026-09-25 |
failure |
a58008a1 |
2026-09-24 |
success ← same commit |
71bc1083 |
2026-09-24 |
success |
22e5b9b4 |
2026-09-24 |
success |
cd6cc902 |
2026-09-24 |
success |
d76055b3 |
2026-09-24 |
failure |
d76055b3 |
2026-09-23 |
success ← same commit |
459f7234 |
2026-09-23 |
success |
459f7234 |
2026-09-22 |
success |
Roughly 2 in 12 runs (~17%) on main, and the failing run is always this same test and assertion.
Also observed on PR #1283 (run 36190540416), which is documentation-only — it changes no src/ file and no tests/Reactor.AppTests/ file, so it cannot plausibly affect DataGrid row-edit behaviour. That is what prompted this report.
Why it matters
At a ~17% per-run failure rate, a green E2E run is weak evidence: three consecutive passes happen about 57% of the time even while the underlying problem persists. So the job currently cannot distinguish "this PR is fine" from "this PR got lucky", and the standard response — re-run until green — silently trains everyone to ignore a red E2E.
Likely shape
The assertion is a WaitForName("Save") timeout, so the suspicion is a race between the row-edit gesture and the Save button being projected to UIA, rather than a wrong result. Worth checking whether BeginRowEditOnFirstRow (DataGridTests.cs:399) needs the same settle/retry the neighbouring interactions use, and whether the preceding click is landing at all on a slower runner.
Not investigated further here — filing so the flake is tracked rather than absorbed.
Repro
Re-running the job on an unchanged commit is sufficient; it passes and fails on the same tree.
Summary
Interactive_DataGrid_RowEditTab_DoesNotSuppressNextCommitintermittently fails in the E2E Tests (winapp ui) job with:This is flake, not a regression — proven by same-SHA disagreement
Two commits on
mainhave both passed and failed the E2E job at the identical SHA, which rules out any code change as the cause:0a04370c8cc49ceac767c0fda58008a1a58008a171bc108322e5b9b4cd6cc902d76055b3d76055b3459f7234459f7234Roughly 2 in 12 runs (~17%) on
main, and the failing run is always this same test and assertion.Also observed on PR #1283 (run 36190540416), which is documentation-only — it changes no
src/file and notests/Reactor.AppTests/file, so it cannot plausibly affect DataGrid row-edit behaviour. That is what prompted this report.Why it matters
At a ~17% per-run failure rate, a green E2E run is weak evidence: three consecutive passes happen about 57% of the time even while the underlying problem persists. So the job currently cannot distinguish "this PR is fine" from "this PR got lucky", and the standard response — re-run until green — silently trains everyone to ignore a red E2E.
Likely shape
The assertion is a
WaitForName("Save")timeout, so the suspicion is a race between the row-edit gesture and the Save button being projected to UIA, rather than a wrong result. Worth checking whetherBeginRowEditOnFirstRow(DataGridTests.cs:399) needs the same settle/retry the neighbouring interactions use, and whether the preceding click is landing at all on a slower runner.Not investigated further here — filing so the flake is tracked rather than absorbed.
Repro
Re-running the job on an unchanged commit is sufficient; it passes and fails on the same tree.