Skip to content

Flaky test: InputDateInteractsWithEditContext_NullableDateTimeOffset #67243

Description

@rokonec

Failing test

Microsoft.AspNetCore.Components.E2ETest.Tests.FormsInputDateTest.InputDateInteractsWithEditContext_NullableDateTimeOffset

Summary

The FormsInputDateTest family of WebAssembly E2E tests is intermittently failing again in the aspnetcore-components-e2e pipeline. These tests drive native date/time <input> elements via Selenium SendKeys, and have a long history of keyboard-input timing flakiness (see #27398, #31734, #34884, #35018). The failures present as the EditContext reporting modified invalid instead of modified valid when keystrokes are dropped/reordered.

InputDateInteractsWithEditContext_NullableDateTimeOffset shares the same root cause and is being re-quarantined alongside its sibling tests on the servicing branches.

Observed CI failure (sibling test in the same class)

Pipeline: aspnetcore-components-e2e

OpenQA.Selenium.BrowserAssertFailedException : Xunit.Sdk.EqualException: Assert.Equal() Failure
Expected: modified valid
Actual:   modified invalid
   at Xunit.Assert.Equal[T](T expected, T actual, IEqualityComparer`1 comparer)
   at Microsoft.AspNetCore.E2ETesting.WaitAssert.<>c__DisplayClass18_0`1.<WaitAssertCore>b__0(IWebDriver _) in /home/vsts/work/1/s/src/Shared/E2ETesting/WaitAssert.cs:line 101

(The captured failure above is for InputDateInteractsWithEditContext_NonNullableDateTime, tracked in #31734. NullableDateTimeOffset exercises the same SendKeys-driven flow and is being quarantined as part of the same group.)

Action

Re-quarantining on the servicing branches so the cookie-auth security backports are not blocked by unrelated flakiness:

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions