A remembered path is trusted only under a folder configured now (#901)

[chchatzop]

Fixes #901. Follow-up to #889, from my review there.

What was wrong

#889 drops the #886 lookup memories on !rehash. But the dashboard's Folders and Lists pages change the library without a rehash: apply_folder_changes() / apply_list_changes() save the file and return, and the folder set is read from that file on every call, so the new roots are live on the very next request. A path remembered under the folder just removed is still on disk, passes the memory's own existence check, and is then refused by is_safe_path() against the new roots: Error: Invalid path. for a file the new configuration serves, for up to LOOKUP_HIT_TTL_SECONDS (5 minutes).

What changed

• dcc.py: a remembered path is trusted only if it is under one of this request's own search_roots - the same is_safe_path() check it is judged by a few lines later anyway. Outside them, the name memory falls through to the folder memory, and that to the scan. This holds however the roots change: the dashboard, a hand-edited lists.json, or a scan still in flight across a rehash that records its hit after the forget.
• A rehash forgets where files were (#886) #889's rehash call stays - it also frees the memory - but it is no longer the only thing between a reconfiguration and a wrong answer.
• test_a_path_from_a_root_that_is_gone_is_refused_rather_than_served asserted the wrong answer, as the documented cost of not forgetting; it is now ..._is_not_used_even_without_a_forget and asserts the right one.

Test

tests/test_a_folder_removed_on_the_dashboard_is_not_served_from_memory.py (3), through the real request path, changing library.folders the way the page's save does (no rehash, no forget): a remembered file is sent from the new root; a remembered folder (the sibling case) falls through the same way; and with the folders unchanged the memory still saves the second scan - #886's point, kept.

Without the dcc.py change, both dashboard tests and the flipped one fail; the control passes both ways. One source guard, test_every_folder_lookup_in_the_request_path_is_scoped, counted a comment of mine that spelled the call out as a fourth unscoped call - the comment was reworded, not the guard.

Verified

Full suite on current main: 6424 OK (18 skipped).

🤖 Generated with Claude Code

https://claude.ai/code/session_01AP6LSxkr4n9dMFNSNMogmW

[chchatzop]

Superseded by #910 (merged), the same check against the current roots. Closing. One nit on #910's version: for candidate in (_remembered_path(...), _in_a_recent_folder(...)) builds the tuple first, so _in_a_recent_folder() - up to LOOKUP_FOLDER_MEMORY (32) os.path.exists calls - runs on every lookup even when the name memory already answered. Free on a local disk; on a library behind a NAS/SMB mount that is up to 32 network stats per request. Checking the folder memory only when the first candidate is out of the roots keeps the same behaviour.