[Bug] Searching bookmarks after deleting a folder returns no results

[seabornlee]

Describe the bug

By investigating issue #5671 , I found that the crash was fixed, but there is a new issue.

How to Reproduce

1. Go to 'Bookmarks'
2. Add folder 'A'
3. Go to folder 'A'
4. Add folder 'B'
5. Delete folder 'B'
6. Search Bookmarks
7. No results at all

screen.mp4

Expected behavior

Should see bookmarks and folder 'A'

Environment

- DDG App Version: 5.231.1
- Device: NIO Phone - N2301
- OS: Android

[github-actions]

Thank you for opening an Issue in our Repository.
The issue has been forwarded to the team and we'll follow up as soon as we have time to investigate.
As stated in our Contribution Guidelines, requests for feedback should be addressed via the Feedback section in the Android app.

[seabornlee]

Another approach to reproduce:

629_1747294275_raw.mp4

[joshliebe]

@seabornlee As stated in #6147 (comment), please submit a smaller targeted PR with the fix.

[Amir-yazdanmanesh]

Hi! I'd like to submit a small, targeted PR for this bug as suggested by @joshliebe.

After investigating the code, the root cause appears to be in SavedSitesRepository.getBookmarksTree(). When a folder is deleted, it's soft-deleted (deleted = 1 in the
entities table), but the relations table can still hold references pointing to the deleted folder. When fetchAllBookmarksAndFolders() is called during search,
getBookmarksTree() uses relationByEntityId() which may return relations to soft-deleted folders, causing the search results to break.

My proposed fix is to add a validation check in getBookmarksTree() to verify that the parent folder referenced by each relation still exists and isn't soft-deleted
before including the bookmark in results. This would be a minimal change (~3-5 lines) in SavedSitesRepository.kt with corresponding test updates.

I'll keep the PR focused on just this fix — no refactoring or unrelated changes.

Is this still available to work on, and does this approach sound right to the team?

---

Want me to adjust anything?
@seabornlee

[mnlmato]

I've opened a PR for this: #9728.

@Amir-yazdanmanesh apologies if this crosses with your work — I couldn't find a PR linked to this issue since February, so I went ahead.

I reproduced it on develop, and the root cause is in BookmarksViewModel rather than in the repository layer. fetchBookmarksAndFolders(parentId) collects getSavedSites(parentId) in a coroutine that is never cancelled, and a new collector is added every time the search bar is closed. Meanwhile fetchAllBookmarksAndFolders() — called when the search bar opens — writes to the same _itemsToDisplay.

Deleting the folder is only committed to the database when the undo snackbar is dismissed. That write makes the still active folder scoped collector re-emit and overwrite the search list with the current folder's contents, which are now empty — hence "no results at all". It also explains why the failure only shows if the search bar is opened while the snackbar is still on screen, which is worth knowing when trying to reproduce it.

The PR keeps a single owner for the displayed list, so opening the search cancels the folder scoped collection, and makes the search list respect pending deletions — which also covers the stale folder half of #5671. Two unit tests in BookmarksViewModelTest fail on develop and pass with the change, and no public API is touched, as @joshliebe asked in #6147.