Filing an observation rather than a reproduction, so it is not silently absorbed. It was chased down at the time and could not be attributed to any change; it has not recurred since.
What happened
tests/test_tui_app.py::test_decision_modal_scrolls_when_content_long failed twice during work on #355, both on full-suite pytest -n auto runs. It has not failed since, across a lot of runs.
| tree |
runs |
failures |
| pre-change (changes stashed) |
8, random seed |
0 |
working tree, --randomly-seed=1..6 fixed |
6 |
0 |
| committed tree |
8, random seed |
0 |
| after the remaining #355 work landed |
~4 full-suite -n auto |
0 |
So: 2 failures in ~22 runs, then 0 in roughly 26 consecutive. Fixed seeds never reproduce it, which rules out test ordering as the cause.
Why it is probably load, not logic
It is a Textual pilot test — await until(...), scroll_visible(animate=False) plus a single pause(), then an _on_screen assertion. That shape is sensitive to event-loop starvation: if the scroll has not been applied by the time the single pause() yields, the assertion reads a stale position. Both failures happened while the machine was concurrently running stash/pop and lint passes, i.e. under unusually heavy load on top of xdist.
Nothing in #355 touches decisions, the dashboard, or the modal (its only tui/app.py edit widens an except tuple in the replan handler), and the pre-change tree was probed 8 times without a failure — so it is pre-existing if it is real.
Suggested fix if it recurs
Replace the single pause() with the same await until(...) predicate the test already uses elsewhere, so the assertion waits for the scroll position to settle instead of assuming one event-loop turn is enough. That removes the timing assumption without weakening what the test checks.
Origin of the test: PR #280 (issue #275, docked modal buttons).
Low priority — but if it starts reproducing at a higher rate, this is the record that it was seen before and was not caused by whatever change is in flight at the time.
Filing an observation rather than a reproduction, so it is not silently absorbed. It was chased down at the time and could not be attributed to any change; it has not recurred since.
What happened
tests/test_tui_app.py::test_decision_modal_scrolls_when_content_longfailed twice during work on #355, both on full-suitepytest -n autoruns. It has not failed since, across a lot of runs.--randomly-seed=1..6fixed-n autoSo: 2 failures in ~22 runs, then 0 in roughly 26 consecutive. Fixed seeds never reproduce it, which rules out test ordering as the cause.
Why it is probably load, not logic
It is a Textual
pilottest —await until(...),scroll_visible(animate=False)plus a singlepause(), then an_on_screenassertion. That shape is sensitive to event-loop starvation: if the scroll has not been applied by the time the singlepause()yields, the assertion reads a stale position. Both failures happened while the machine was concurrently running stash/pop and lint passes, i.e. under unusually heavy load on top of xdist.Nothing in #355 touches decisions, the dashboard, or the modal (its only
tui/app.pyedit widens anexcepttuple in the replan handler), and the pre-change tree was probed 8 times without a failure — so it is pre-existing if it is real.Suggested fix if it recurs
Replace the single
pause()with the sameawait until(...)predicate the test already uses elsewhere, so the assertion waits for the scroll position to settle instead of assuming one event-loop turn is enough. That removes the timing assumption without weakening what the test checks.Origin of the test: PR #280 (issue #275, docked modal buttons).
Low priority — but if it starts reproducing at a higher rate, this is the record that it was seen before and was not caused by whatever change is in flight at the time.