Overview
test_monitor_filter_narrows_glance_bar_and_shows_match_count
(tests/e2e/test_monitoring_ui.py:304) failed once in CI expecting
"1 of 3 shown", and passed on the same commit's code in three later runs on the
same branch. Order- or timing-sensitive, pre-existing, and unrelated to whatever
branch happens to be red when someone next sees it.
Details
Use Case / Steps:
- Run the
e2e suite in CI.
- Occasionally this one test fails at the filter assertion.
- Re-run it; it passes.
Expected vs Actual:
- Expected: deterministic, since the test injects its own stats payload and
never touches a real host.
- Actual: one failure in four observed runs of the same code.
Details:
Observed during #284's CI rounds. That branch touches no Monitor code and no
frontend at all, which is what makes it worth recording: the next person to see
this red will reasonably start by suspecting their own diff.
The test fills #monitor-container-filter and then asserts, in order,
#monitor-filter-count, #mstat-running, #mstat-total and #mstat-stopped.
Everything is injected, so the likely candidate is the filter input event racing
the re-render rather than any real data timing. The suite runs -n auto, so
worker-dependent ordering is also in scope.
Scope:
Reproduce first, ideally by running that module alone in a loop, before changing
anything. If the race is the fill-then-assert sequence, the fix is on the test
side; if the re-render genuinely drops an update, it is not.
Recorded so the next red run does not cost a debugging session on the wrong branch.
Overview
test_monitor_filter_narrows_glance_bar_and_shows_match_count(
tests/e2e/test_monitoring_ui.py:304) failed once in CI expecting"1 of 3 shown", and passed on the same commit's code in three later runs on thesame branch. Order- or timing-sensitive, pre-existing, and unrelated to whatever
branch happens to be red when someone next sees it.
Details
Use Case / Steps:
e2esuite in CI.Expected vs Actual:
never touches a real host.
Details:
Observed during #284's CI rounds. That branch touches no Monitor code and no
frontend at all, which is what makes it worth recording: the next person to see
this red will reasonably start by suspecting their own diff.
The test fills
#monitor-container-filterand then asserts, in order,#monitor-filter-count,#mstat-running,#mstat-totaland#mstat-stopped.Everything is injected, so the likely candidate is the filter
inputevent racingthe re-render rather than any real data timing. The suite runs
-n auto, soworker-dependent ordering is also in scope.
Scope:
Reproduce first, ideally by running that module alone in a loop, before changing
anything. If the race is the fill-then-assert sequence, the fix is on the test
side; if the re-render genuinely drops an update, it is not.
Recorded so the next red run does not cost a debugging session on the wrong branch.