Skip to content

fix(import): keep the inbox honest while the staging scan runs - #1679

Merged
Nezreka merged 2 commits into
devfrom
fix/1671-import-scanning-status
Oct 13, 2026
Merged

Nezreka merged 2 commits into
devfrom
fix/1671-import-scanning-status

Conversation

@Nezreka

@Nezreka Nezreka commented Oct 12, 2026

Copy link
Copy Markdown
Owner

fixes #1671. on a big batch the import page blanked out and said the folder wasnt configured. it was configured fine — the background staging scan's reply only carried the scan progress, so the page had no path, no items and no worker state to show, and it read the empty reply literally. small batches never saw it because their scan finishes inside the grace window.

what changed:

  • the scanning reply now names the staging folder, so "not configured" only shows when it actually isnt
  • while a scan runs, the inbox serves what doesnt depend on the scan: the worker state (auto-import switch stays) and the history rows from the db. unfinished rows (needs review, needs identify, queued, importing, failed, partial) come back as staged rows with their real status — one row per folder, newest attempt wins, since a folder's hash changes when its files do. failed rows keep their retry button during scans
  • the page keeps the last complete list under a "reading the import folder… n of m files" banner instead of swapping the list out, merging in any fresher rows the scanning reply carries
  • bulk approve/dismiss dedupe history ids so a duplicated row cant strand the rest of the selection
  • "import complete — nothing left to import" toast when a batch finishes: it arms when a batch is seen staged and only fires when that same folder later reads empty, nothing is live, the worker is idle, and the worker's own imported count moved past the arm point. files that just vanish (deleted over the network, path changed) dont announce, and a worker restart cant poison the baseline

known limits, stated plainly:

  • a first-ever drop opened mid-scan still shows 0 counts until the first scan lands — those files have no db row yet, so there is nothing honest to show. the path, the switch and the progress banner are all there now though
  • the completion toast is for auto-import batches. manual imports from the matcher dont move the worker's counter, so they dont announce

tests: backend staging-scan file 19/19 (incl. one-row-per-folder with rehashed and same-hash retries, history caching, broken worker), frontend import suite 50/50 (incl. merge identity by history id, toast fire / no-fire / restart re-arm). the wider tests/imports failures (47 + 17 errors) are identical on base — missing modules in this env, not this change. two hostile review rounds, findings folded.

@Nezreka
Nezreka force-pushed the fix/1671-import-scanning-status branch from 5d4a703 to 296d4d7 Compare October 12, 2026 23:05
@Nezreka
Nezreka force-pushed the fix/1671-import-scanning-status branch from 296d4d7 to 342e87a Compare October 12, 2026 23:12
…upe, history cache invalidation, live progress
@Nezreka
Nezreka merged commit 4ac5b02 into dev Oct 13, 2026
4 checks passed
@Nezreka
Nezreka deleted the fix/1671-import-scanning-status branch October 13, 2026 00:14
This was referenced Oct 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant