2 Commits

Include renames

Author	SHA1	Message	Date
QuickandGitHub	10394b0a05	fix(scanner): stop hiding media when a library root is offline (#472) ... * fix(scanner): stop hiding media when a library root is offline A scan that cannot read a library root found no files there, so every cataloged file under it was marked missing. Catalog reads all filter on missing_since IS NULL, so marking is equivalent to deletion from a user's point of view: the title leaves browse, search and next-up, and playback answers "Source media file is missing" for media that is intact on disk. The dead-root protection already existed but only guarded the destructive operations. protectedConfiguredRoots was computed *after* the marking loop in scanPaths, and applyScopedScan received the protected set but applied it only to its force-delete branch. So an unreachable root could not lose its rows, but could still have its entire catalog hidden until the next successful scan. On a CephFS deployment whose per-library subvolume mounts flap, this marked 190 present files missing in a single day — 15% of all missing-flagged rows were files sitting untouched on disk, some flagged more than 20 hours after their last write. Hoist the probe above the marking loop and skip files under an unreachable or suspect-empty root in both the folder and scoped paths. Pass the unreachable set to the walked-scope call too: a nested child mount can die under a healthy parent, and its rows are inside the parent's scope. An offline root tells us nothing about whether its files exist. The only safe reading is to leave them alone and let the next good scan decide. Genuine deletions under a reachable root are unaffected and still marked and swept on the same schedule as before. Report the count as ScanResult.MissingSkippedProtected and log it, so an operator can tell "my library shrank" from "my mount dropped". Known gap: a suspect-empty *nested child* root under a healthy parent is still marked missing, because the suspect set is not resolved until after the walk loop. Unreachable roots — the case observed in production — are covered. * fix(scanner): protect suspect-empty and partially-walked roots too Addresses review findings on #472. The original change guarded missing-marking against probe-unreachable roots, but left three ways for a storage fault to still hide a healthy library. Suspect-empty detection was reactive. suspectEmptyRoots asked ListRootsWithOnlyMissingFiles, which returns a root only once it has NO live rows left. On the first scan after a mount drops — the moment that matters — the rows are still live, so the root was not classified suspect and the scan marked everything missing. The protection then engaged on the next scan, in time to protect the wreckage. Ask ListRootsWithCatalogedFiles instead: any cataloged row under an empty-but-reachable root is the lost-mount signature. Intentional emptying is still reachable through the operator's one-time cleanup allowance, which is the deliberate path for it. Nested suspect-empty children were unprotected. Root compaction sends only the populated parent through the walked-scope branch, which received only unreachableRoots, so an empty child mountpoint had its rows marked missing on its parent scanning cleanly. Pass the suspect set as well. Partial walks were treated as authoritative. walkLogicalTree deliberately swallows per-entry Lstat/ReadDir failures so one bad file cannot abort a scan of a million, and collectLogicalFilePaths passed nil for the failure counter — so the video path had no signal at all. A mount dying partway through traversal produced a short file list indistinguishable from a large deletion. Thread the counter through, and exclude a scope whose walk came back incomplete from missing reconciliation, mirroring what the ebook scanner already does via ebookRootScan.failed. Also extract the duplicated mark-missing loop into markMissingExcludingProtected so the folder and scoped paths cannot drift, and correct two comments that still described the pre-fix "files are marked missing" behaviour — the exact text a future reader would have trusted when reintroducing this bug. TestScanFolderNestedSuspectEmptyChildRootProtection asserted the old behaviour and is updated accordingly. * fix(scanner): scope walk-failure protection and stop pruning on partial walks Addresses the second Codex review round on #472. The previous commit's incomplete-walk protection was too blunt in one direction and applied too late in another. Walk failures were counted, not located, and any non-zero count protected the whole library root. A dangling symlink is both common and permanent, so that would have suppressed missing-file reconciliation for its entire root on every future scan — genuinely deleted titles would stay live indefinitely. That is the same class of bug as the one this PR fixes, pointing the other way. recordWalkFailure now records the logical path of each unreadable entry, and only those paths are protected. Per-entry failures record the child path, so a dangling symlink protects itself and nothing else, while a directory that cannot be read protects its subtree. Snapshot and group pruning ran before the protection. reconcileScannedRoots and reconcileScannedGroups delete whatever the walk did not see, and both run ahead of the missing-file guard, so a partial walk still dropped root snapshots, observed locations and group locations for the unread portion — corrupting later metadata matching even though the media_files rows survived. Upserting what was seen is always safe; pruning now waits for a scan that read the whole tree. The confirmed-cleanup allowance was consumed to no effect for nested suspect children. The walked-parent branch protected them unconditionally and runs before the allowance is consumed, and an already-reconciled scope cannot be revisited — so arming the allowance burned the confirmation while the child's rows stayed live forever. Read the allowance without consuming it before the walk loop, and honour it there. Unreachable roots stay protected either way: an outage is never a confirmation to erase a catalog. Two new regression tests, plus signature updates in the ebook pipeline, which already tracked walk failures and now shares the path-based representation. * fix(scanner): re-probe nested roots and gate group pruning on walk completeness Third Codex review round on #472; both findings confirmed. Group pruning ignored walk completeness in the subtree path. scanPaths passed the completeness decision to reconcileScannedRoots but left reconcileScannedGroups on !allowEmptyRootGuard, which is always true for ScanSubtree — so a subtree scan that hit an unreadable directory still replaced group snapshots and locations from a partial inventory. Same rule now applies to both. Nested roots were not re-probed before their parent was reconciled. Root compaction folds a child mount into its parent for traversal, so a child that is healthy at the initial probe but drops before the parent is walked leaves no scope of its own, and the post-walk re-probe only revisits scopes that walked empty. The parent walks files, looks healthy, and the child's rows are marked missing on its success. reprobeNestedRoots re-checks this root's configured children immediately before reconciling, protecting any that have since become unreachable — or suspect-empty, unless the operator has confirmed cleanup. Also guard suspectEmptyRoots against a nil file repository, matching emptyCleanupArmed: without a catalog there is nothing to protect. * fix(scanner): keep re-probed outages protected through folder-wide cleanup Fourth Codex review round on #472; both findings confirmed. The first could destroy data. reprobeNestedRoots protected a root it found offline only for the scope being reconciled, then discarded the result. The folder-wide membership reconcile and the trash sweep afterwards rebuilt their protected set from the initial probe alone, so rows under a child that dropped mid-scan — already marked missing and past the removal grace — were hard-deleted by the very scan that noticed the outage. Accumulate those roots in reprobedRoots, fold them into protectedScanRoots, and reuse that set for the membership reconcile and sweep instead of rebuilding. They now also land in ScanResult.UnreachableRoots so the folder warning reflects the outage rather than presenting a partial scan as clean. Snapshot and group pruning was enabled for scopes that were never walked. The gate was len(walkFailures) == 0, but an unreachable root gets nil walkRoots, so it has no walk and therefore no failures — and pruning then deleted its snapshots, observed locations and group locations even though its media rows were protected. The same held for a suspect-empty child compacted into a populated parent. Pruning now additionally requires that the scope was actually walked and contains no protected path. The new test pins that the sweep honours the protected set it is given. It does not reproduce the mid-scan race itself: staging that needs the drop to land between the probe and the walk, which a test cannot reach without hooks. That path is covered by inspection, and the test comment says so rather than implying coverage it does not have. * fix(scanner): route every protection source through one folder-wide set Fifth Codex review round on #472. Two P1s, one of them the second data-loss path in this area — and the direct sibling of the one fixed in 35326adc, which is the reason this commit changes the structure rather than patching another edge. Rows beneath a directory the walk could not read were protected only inside applyScopedScan. The folder-wide protected set was rebuilt from the probe results alone, so DeleteMissingByFolder could permanently delete rows past the removal grace under a subtree this scan never managed to read — deleting on the strength of an observation that was never made. The recurring defect is structural: protection is discovered in several places (initial probe, mid-loop re-probe, per-scope walk failures) and consumed in several more (scoped reconcile, membership reconcile, trash sweep), and each fix so far has wired up one edge and missed another. Every source now accumulates folder-wide and every consumer reads the combined set, so a new source has one place to register instead of several to remember. reprobeNestedRoots classified from two probe batches. It called probeUnreachableRoots, then suspectEmptyRoots probed the same paths again; a child dropping between the samples was reachable to the first and discarded by the second, which only returns reachable-and-empty roots. It now classifies both states from one batch, so the disconnect it exists to catch cannot fall between its own probes. Re-probed roots kept their classification instead of being collapsed into unreachableRoots, which had been reporting a suspect-empty child as unreachable and giving operators contradictory failure information. The new regression test is verified to fail with the propagation disabled and pass with it, rather than assumed to cover the path. Not addressed: the cleanup allowance is read without being reserved, so two overlapping full scans of one folder can both observe it armed. Narrow, needs a transactional reserve in the scan-claim query, and is left for follow-up rather than bundled here. * fix(scanner): resolve root protection before scoped metadata pruning Sixth Codex review round on #472. scanPaths pruned before it knew what was protected. reconcileScannedRoots and reconcileScannedGroups ran roughly 160 lines ahead of protectedConfiguredRoots, so a ScanSubtree of a mount that dropped but left a reachable empty mountpoint walked clean, reported no failures, and pruned root snapshots and observed and group locations against that empty inventory — preserving the media rows while deleting the metadata describing them. Protection is now resolved before any reconciliation, and both prunes share one decision, matching applyScopedScan. Pending empty scopes never re-probed their nested children. A parent whose only media lives in a child walks empty when that child drops, so it lands in pendingEmptyScopes rather than the populated-scope branch where reprobeNestedRoots ran. Probing the parent alone proves nothing: it still holds the child's bare mountpoint directory, so it reads present and non-empty. With a healthy sibling keeping the folder-wide empty guard quiet, nothing protected the child. Both branches now re-probe. MissingSkippedProtected never left the scanner. Both ingest-to-result conversions copied every other cleanup count but not this one, and events.ScanRunResult had no field, so scan history, completion events and API responses reported an all-zero no-op for a scan that skipped files because storage was offline. Added as a new field, which is additive under the v1 API rules. Test honesty: the new test does NOT exercise the pending-scope re-probe. It empties the child before the scan, so the initial probe classifies it and protection arrives by that path — verified by confirming the test still passes with the re-probe disabled. It is named and commented for what it does cover. The mid-scan race behind both re-probe fixes needs the drop to land between the probe and the walk, which is not reachable from a test without hooks; those fixes rest on inspection.	2026-07-25 14:47:12 -04:00
5 people	8fc054c15d	fix(scanner): never purge files under unreachable library roots (#372) ... * fix(scanner): never purge files under unreachable library roots An unreachable root is not a removed root. When one root of a multi-root library dies (unmounted share, dead drive) while another root still has files, the whole-library empty-root guard does not fire — the surviving root produced files — so the scan marks everything under the dead root missing_since (desired: hides it from browse/playback) and then, with the default scanner.empty_trash_after_scan=true + 24h file_removal_grace, the next scan after the grace hard-deletes every row under the dead root. A week-long drive outage silently destroys the root's entire catalog state: probe data, intro/credits markers, file hashes. Worse, membership reconciliation immediately purges media_items whose only files lived on the dead root, cascading user collections (library_collection_items has ON DELETE CASCADE) and deleting cached artwork. This change makes "temporarily offline" survivable: - Probe each configured root at scan start (os.Stat + IsDir + ReadDir, factored into the new internal/rootcheck package and shared with the admin mount-check endpoint). Unreachable roots are skipped by the walk but their scopes still reconcile, so files are still marked missing. - The trash sweep (DeleteMissingByFolder) now excludes rows whose path sits under an unreachable root, using the same exact-path + escaped prefix-LIKE matching as ListIDsOutsideRoots (a sibling root that merely shares a string prefix is never protected). With all roots reachable the emitted SQL is unchanged. - Membership removal still happens — browse/home hide items via media_item_libraries, so removal is what keeps a dead-root-only title out of the catalog — but the orphan media_items purge exempts items whose files sit under an unreachable root. Their metadata, artwork, and collection links survive; when the root returns, the upsert clears missing_since and syncPresentLibraryState re-inserts the membership, restoring the item with zero re-probing or re-matching. - The folder surfaces scan_warning_code='dead_root' with a message naming the unreachable roots; a fully healthy scan or a successful mount check clears it, mirroring empty_root. The admin UI shows a badge and banner. - Deliberate deletion is untouched: removing a path from the library config still purges via ListIDsOutsideRoots, files under reachable roots keep the exact 24h-grace purge, the empty-root guard and the autoscan dead-mount guard are unchanged. The audiobook/podcast/ebook reconcile paths share the same folder-wide sweep and orphan purge, so they get the same guard. Covered by tests: an end-to-end two-root scan (root dies -> rows survive a zero-grace sweep and warning is set; root returns -> rows resurrect with their original ids and the warning clears; deleting a file under a reachable root still purges), repo-level sweep-protection and sibling-prefix tests, orphan-purge exemption, and rootcheck unit tests. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * fix(scanner): probe uncompacted roots and take dead-root path on full outage Review follow-ups: (1) probe every configured path instead of the compacted traversal roots, so a nested child mount that dies under a reachable parent is still protected from the sweep; (2) when every configured root is unreachable, bypass the empty-root confirm flow (without consuming the one-time cleanup allowance), mark files missing, and raise dead_root instead of empty_root; (3) dead_root warning banner no longer shows empty-root confirm-deletion guidance as its fallback hint. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> * refactor(scanner): simplify dead-root protection plumbing - extract pathscope.CoverageClauses as the single builder for the exact-path + escaped prefix-LIKE root predicate; scanner's rootCoverageClauses delegates to it and catalog's excludeOrphansUnderProtectedPrefixes reuses it instead of hand-rolling the same clause loop - extract Scanner.sweepMissingAndReconcile to replace the identical trash-sweep + membership-reconcile + S3-image-cleanup block that was triplicated across the audiobook, ebook, and podcast scans (callers keep their flavor-specific log lines so messages stay constant) - add unreachableConfiguredRoots helper for the repeated probeUnreachableRoots(ctx, folder.ID, cleanScanRoots(folder.Paths)) expression in scanPaths and ScanFile - drop the unread Path field from rootcheck.Result - move the dead/empty-root warning text constants in AdminLibraries.tsx out of the middle of the import block Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(scanner): close dead-root protection gaps found in review Remediates the confirmed findings from the deep review of this PR: - Scoped audiobook scans (autoscan file events, subtree scans) ran the folder-wide sweep while probing only the scoped clone's Paths, so a healthy-subtree event could hard-delete a dead sibling root's rows. sweepMissingAndReconcile now reloads the folder's configured roots from the DB and probes them uncompacted, which also protects nested child mounts in the audiobook/ebook/podcast reconcilers. - A lost mount that leaves an empty, stat-able mountpoint probed as reachable and kept the historical purge timeline. A reachable root that is a literally empty directory while cataloged rows remain under it is now treated as suspect: rows are only marked missing, the sweep and orphan purge exempt it, dead_root is raised, and the mount-check endpoint reports it (additive suspect_empty field) instead of clearing the warning. Arming the one-time empty-cleanup allowance completes the deletion, including in the mixed case where other roots are healthy. Roots that still have directory entries keep the historical grace-then-purge path. - Confirmed empty cleanup (allow_empty_cleanup_once) no longer force-deletes rows under probe-dead roots: an outage is not a confirmation, so a dead sibling root's catalog survives a confirmed cleanout of a reachable empty root. - Root probes are now bounded (rootcheck.ProbeWithTimeout, 5s): a hung network mount degrades into the protected unreachable path with a probe_timeout error code instead of stalling every scan of the folder indefinitely. - Documented the cross-library limitation of the orphan-purge exemption next to the query it applies to. All behavior is pinned by new DB-backed tests (suspect-empty protection + confirmed completion, confirmed-cleanup dead-root survival, scoped/nested-root sweep protection, suspect-root query, probe timeout). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(scanner): address dead-root review findings --------- Co-authored-by: rxwatcher <rxwatcher@users.noreply.github.com> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: Quick104 <31828688+Quick104@users.noreply.github.com>	2026-07-16 13:58:44 -04:00