Repository navigation
test_gui filter tests fail intermittently on a clean main #14
Description
Symptom: tests/test_gui.py::test_escape_clears_the_filter_and_returns_to_the_tree, test_clearing_the_filter_restores_everything and test_filter_narrows_the_listing fail on some runs of the full file (3 of 4 runs on main for the first, offscreen platform, Windows). Isolated runs with -k pass.
Cause: not found. Replacing the fixed pump(300) sleeps with polling for up to 5 s did not remove the failures, so the filter is sometimes never applied to the QFileSystemModel listing rather than applied late. Suspects are state left by earlier tests in the same QApplication, or the filter proxy depending on an event that offscreen does not deliver.
Reproduce: uv run pytest tests/test_gui.py repeatedly on main; compare with uv run pytest tests/test_gui.py -k filter.
Activity
NaNIsaac commentedon Oct 21, 2026
Findings so far (Windows, offscreen, 4 to 6 runs each):
Not yet tried: whether _select_in_tree_when_loaded leaves a directoryLoaded connection that blocks later loads, whether setRootPath on a path the previous model already watched matters, and running the navigation tests last (-p no:randomly with reordered ids).
NaNIsaac commentedon Oct 21, 2026
Two more leads ruled out by reading the code: the app never calls os.chdir or QDir.setCurrent, and MainWindow._restore_session skips last_dir when it is under the temp directory (it removes the key instead), so a restored parent directory cannot be the cause for pytest tmp_path folders.
NaNIsaac commentedon Oct 21, 2026
Cause found and fixed in #22. The
main_windowfixture onlyclose()d windows, so every MainWindow and its QFileSystemModel stayed alive for the session, andprocessEventsslowed until the filter tests saw unpopulated listings. Full-file runs on main: 3 and 1 failures (281 s, 45 s). Main plus the teardown change alone: 33 passed in 9 s. #22: 33 passed in 4 of 4 runs, and again under 100 % CPU load. The earlier load hypothesis was wrong: main fails on an idle machine when the whole file runs.NaNIsaac commentedon Oct 22, 2026
Reading the code for the two D7 hypotheses (cwd /
QDir.current, andQSettings); nothing was run.src/andtests/contain noos.chdir,QDir.setCurrentorQDir.current. The only way the working directory could change is through the file dialog, and the filter tests do not open one.isolated_qsettingsfixture (tests/conftest.py) redirects the INI store to a temp folder, andmain_windowcallsQSettings("QoraDFXM", "ImageAnalyzer").clear()before eachMainWindow().closeEventwriteswin_geometryandwin_stateback, which the next test clears again._restore_sessionignoreslast_dirandlast_fileunder the temp directory and removes the keys. So a test cannot inherit another test's folder through settings.Both hypotheses are ruled out by the code, which agrees with the earlier comment and with the cause found in #22: windows and their
QFileSystemModelwere never deleted, so they accumulated for the whole session. D7 needs no further work once #22 is merged.One thing worth keeping from #22's diff: the
main_windowteardown relies onwin._fs_modelexisting; a window built without it would fail the fixture, not the test.NaNIsaac commentedon Oct 22, 2026
New measurement on the branch of #22 plus the arrow-key change (#25), 10 whole-file runs under 12 busy-loop processes while other jobs also ran on the machine: 7 passed, 3 failed, all three in
test_filter_narrows_the_listing, waiting forUNFILTEREDwithlisting=[] rowCount=0 canFetchMore=Falseafter 10 s, root valid. The earlier campaign on #22 (10 whole-file runs and 20 filter-only runs under the same load) saw no filter failure, so the machine was busier this time. Details and the caveat are in the comment on #25.If this reproduces on an otherwise idle machine plus the busy loops,
QFileSystemModelcan still fail to populate on #22, and the cause in this issue is only partly fixed. #8 was closed as a duplicate of this issue on the strength of the earlier campaign.test(gui): delete each test's window and file model on teardown
test(gui): wait for the explorer listing instead of fixed pumps
NaNIsaac commentedon Oct 22, 2026
Controlled rerun B16b on main (with #22): 19/20, one empty-listing timeout under full CPU load; the failing state shows the right root path and filters, so it does not look like this issue's stale state. Details and the registered verdict are on #8, which is reopened.