Repository navigation
GUI filter tests are timing-dependent and fail under load #8
Description
Symptom
In a full QT_QPA_PLATFORM=offscreen uv run pytest run, the filter tests in tests/test_gui.py fail intermittently (seen 2026-10-22 on main and on a branch with only uv.lock changes), for example:
test_filter_narrows_the_listingtest_filter_survives_changing_foldertest_escape_clears_the_filter_and_returns_to_the_treetest_clearing_the_filter_restores_everything
Run on their own (pytest tests/test_gui.py -k filter) they pass.
Cause
The tests wait a fixed time with pump(300) and then read the listing. The listing fills asynchronously (the directory model loads in the background) and the filter applies after the 120 ms single-shot _filter_timer in gui/main_window.py. On a loaded machine, 300 ms is not always enough, so the assertion reads a listing that is not populated or not filtered yet.
Reproduce
Run the whole suite while the machine is busy (for example with another test suite running in parallel). A full run took about 200 s here and 3 of the filter tests failed.
Fix
Replace the fixed pump(ms) before each listing assertion with a wait-until helper that pumps events until the expected condition holds or a timeout (a few seconds) passes, and fails with the last listing on timeout.
Activity
NaNIsaac commentedon Oct 22, 2026
Checked on the branch of #22 (6badf80), Windows,
QT_QPA_PLATFORM=offscreen, with 12 busy-loop processes on a 12-thread machine so every core was at 100 %. One pytest process per run.tests/test_gui.py -k "filter or escape or clearing"(the four tests of this issue plus the escape test)tests/test_gui.py,-xtest_arrow_keys_move_the_preview(below)The filter tests never failed: in the whole-file runs they come before line 438, so every one of the 10 runs passed them. That matches the measurement in #14 (cause: windows and file models never deleted; fixed in #22), so what this issue describes, filter tests failing under load, is the same problem and #22 fixes it. Closing as a duplicate of #14.
The whole-file runs do show a different weakness, filed separately:
test_arrow_keys_move_the_previewstill polls for the model for a fixed 2 s (for _ in range(20): pump(100)), and under full CPU load the folder is not populated in time (assert 0 >= 2). The script isb16_repeat_under_load.pyin the ops scratchpad; not in the repository.NaNIsaac commentedon Oct 22, 2026
The separate issue for the arrow-key tests is #24.
NaNIsaac commentedon Oct 22, 2026
Reopening: the controlled rerun registered in advance (lab backlog B16b) failed once on main.
Rule, fixed before the runs: 20 runs of the filter tests (
-k "filter or escape or clearing", 6 tests) under CPU load from 12 busy-loop processes and nothing else; 20/20 on main means the earlier failures came from other jobs' load and this stays closed, a single failure means #22 did not finish the job and #8 reopens.Result (2026-10-23, Windows 11, Ryzen 5 7500F, 12 logical cores, offscreen Qt,
docs/b16_repeat_under_load.py --runs 20):test_clearing_the_filter_restores_everythingtest_filter_keeps_folders_visibleBoth failures print the same state after the 10 s wait:
The root path, the name filters and the filter timer are all as the test set them; only the listing is empty. That is not the stale-state symptom of #14. A likely reading, not verified: with every core busy, QFileSystemModel's background gatherer did not deliver the folder within 10 s.
Caveat on the condition: load snapshots before and after the runs also showed the Everything file indexer (about one core over 3 s, at 05:45 and at the end) and Windows Defender (1.0-1.7 cores), so "nothing but the busy loops" was not fully met. The registered verdict stands as written; this is recorded next to it, not instead of it.
Next test that would separate the two readings: the same 20 runs with one core left free (11 workers) or with the wait raised to 30 s. If the failures go away, the cause is gatherer latency under saturation (a test timing budget), not a state leak.
NaNIsaac commentedon Oct 22, 2026
Controlled rerun B16c (registered in advance, run 2026-10-23 07:03-07:20 with nothing else on the machine; the Everything indexer was running but idle, no other process above 0.6 core): (a) 11 load workers, 10 s wait: 20/20; (b) 12 load workers, 30 s wait: 20/20. Registered verdict: gathering delay under CPU saturation, not state leakage. The timeout change is in the PR that references this issue; it closes this when merged.