Summary
tests/e2e_ui/scheduled/test_scheduled_tasks_page.py::test_scheduled_task_create_edit_modal_and_time_picker[chromium] fails intermittently (~50%) in the E2E UI Tests (shard 1/3) job. It's a newly-added test (2026‑07‑23) and is not yet in tests/known_failures.yaml, so it's currently red‑barring unrelated PRs.
Failure
Playwright times out clicking the minute cell in the scheduled‑task time picker — the element is asserted visible immediately before, yet the click(force=True) hangs for the full 30s:
expect(page.get_by_test_id("schedule-minute-37")).to_be_visible() # passes
page.get_by_test_id("schedule-minute-37").click(force=True) # <-- times outplaywright._impl._errors.TimeoutError: Locator.click: Timeout 30000ms exceeded.
Call log:
- waiting for get_by_test_id("schedule-minute-37")
Because the cell is confirmed visible one line earlier, this looks like the click is being intercepted (overlay/animation) or the cell sits in a scrolling/virtualized minute list where the click never lands — not the element being absent.
It's flaky, not a real regression (independent of the change under test)
Same shard‑1/3 failure on three PRs with unrelated diffs, at different heads:
…while other recent PRs (e.g. #3229, #3223) passed the same shard. So it's ~50% across PRs, independent of the change under test.
Introduced
tests/e2e_ui/scheduled/test_scheduled_tasks_page.py was added 2026‑07‑23:
Suggested action
- Short term: quarantine in
tests/known_failures.yaml so it stops red‑barring unrelated PRs.
- Root cause: likely a race between the time‑picker opening/animating and the
click. Consider waiting for the picker's stable state (scroll‑into‑view / wait for the open animation to settle) and clicking without force once the overlay is done, rather than force‑clicking mid‑transition.
Filed by an external contributor who hit this on #1470 (a backend‑only change). Happy to help if useful.
Summary
tests/e2e_ui/scheduled/test_scheduled_tasks_page.py::test_scheduled_task_create_edit_modal_and_time_picker[chromium]fails intermittently (~50%) in the E2E UI Tests (shard 1/3) job. It's a newly-added test (2026‑07‑23) and is not yet intests/known_failures.yaml, so it's currently red‑barring unrelated PRs.Failure
Playwright times out clicking the minute cell in the scheduled‑task time picker — the element is asserted visible immediately before, yet the
click(force=True)hangs for the full 30s:Because the cell is confirmed visible one line earlier, this looks like the click is being intercepted (overlay/animation) or the cell sits in a scrolling/virtualized minute list where the click never lands — not the element being absent.
It's flaky, not a real regression (independent of the change under test)
Same shard‑1/3 failure on three PRs with unrelated diffs, at different heads:
c1658f8d, a backend terminal‑registry change, no UI surface): https://github.com/omnigent-ai/omnigent/actions/runs/30097937963/job/89496865451ce62de1c): https://github.com/omnigent-ai/omnigent/actions/runs/30089597347/job/89469813406dced5def): https://github.com/omnigent-ai/omnigent/actions/runs/30084331047/job/89453153827…while other recent PRs (e.g. #3229, #3223) passed the same shard. So it's ~50% across PRs, independent of the change under test.
Introduced
tests/e2e_ui/scheduled/test_scheduled_tasks_page.pywas added 2026‑07‑23:Suggested action
tests/known_failures.yamlso it stops red‑barring unrelated PRs.click. Consider waiting for the picker's stable state (scroll‑into‑view / wait for the open animation to settle) and clicking withoutforceonce the overlay is done, rather than force‑clicking mid‑transition.Filed by an external contributor who hit this on #1470 (a backend‑only change). Happy to help if useful.