https://bugs.kde.org/show_bug.cgi?id=434926
--- Comment #22 from James C. Owens <[email protected]> --- The merge request is up: https://invent.kde.org/frameworks/baloo/-/merge_requests/297 It is stacked on !296, a separate series about index-removal batching and index/filesystem reconciliation, so !297 currently shows that series' commits as well as its own. Only its final commit -- "[engine] Bound removeRecursively and stop following disowned id tree edges" -- is the fix described above. Once !296 lands, !297 will be rebased and the rest will drop off. Two corrections to my comment above, worth making here rather than leaving the record wrong. First, the stale-edge state is narrower than I implied. Re-homing a document through the ordinary path -- replaceDocument() with DocumentUrl -- routes through DocumentUrlDB::updateUrl(), which unlinks from the previous parent correctly. Reaching the state needs addDocument() to be called on an id that is already present, and four of its five call sites guard against exactly that with hasDocument(). ModifiedFileIndexer does not: it guards on "isKnownFile && job.document().id() == fileId", so a path whose inode changes between the scheduler's stat and BasicIndexingJob's own falls through to addDocument(). Second, and this is what makes it matter: the Q_ASSERT(!documentTermsDB.contains(id)) in WriteTransaction::addDocument() would catch that, but it is compiled out of release builds. The shipped libKF6BalooEngine on a distro build contains no assertion strings at all. So rather than aborting, the double-add silently leaves the id in both parents' child vectors -- and DocumentUrlDB::add() performs no unlink, unlike updateUrl() and del(). The MR carries a test for the mechanism itself (that DocumentUrlDB::add() leaves the old parent edge in place) and separate tests for the walker refusing to follow such an edge, each mutation-tested. -- You are receiving this mail because: You are watching all bug changes.
