Undo doesnt refresh the Card Browser's row list after deleting a note

[GuTS805]

Checked for duplicates?

• This issue is not a duplicate

Does it also happen in the desktop version?

• This bug does not occur in the latest version of Anki Desktop

What are the steps to reproduce this bug?

1. open the card browser
2. select a note and delete it
3. tap "undo" on the snackbar that pops up

Expected behaviour

the note should reappear in the browser list since its actually restored

Debug info

AnkiDroid Version = 2.24.0 (ebcf8e0e34921628b9b8a496c66ffd4adbb3705f)  
Backend Version = 0.1.64-anki25.09.2 (25.09.2 3890e12c9e48c028c3f12aa58cb64bd9f8895e30)  
Android Version = 13 (SDK 33)  
ProductFlavor = play  
Device Info = OnePlus | OnePlus | OP555BL1 | IV2201_IND | IV2201 | mt6877  
WebView Info = [com.google.android.webview | 787118103]: Mozilla/5.0 (Linux; Android 13; IV2201 Build/TP1A.220905.001; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/150.0.7871.181 Mobile Safari/537.36  
ACRA UUID = bbe8603c-4564-4f9f-9621-e2c7e5b9b556  
FSRS = 5.1.0 (Enabled: false)  
Crash Reports Enabled = true

(Optional) Anything else you want to share?

dug into this a bit. CardBrowserViewModel.deleteSelectedNotes() calls refreshSearch() itself after deleting, but undo doesnt go through that path at all. tryUndo() in Undo.kt just calls undoableOp { undo() } with no handler, and the only thing listening (CardBrowserFragment.opExecuted) just calls notifyDataSetChanged() which re-renders the same stale list instead of re-searching.

so the note does actually come back in the collection, col.cardCount() proves it, but the browser just never re-queries to show it. wrote a test confirming this fails on main right now. already have a fix idea (make the viewmodel subscribe to changes and refresh, or have opExecuted call refreshSearch instead of just notifyDataSetChanged), will open a PR

Research

• I have checked the manual and the FAQ and could not find a solution to my issue
• (Optional) I have confirmed the issue is not resolved in the latest alpha release (instructions)

[GuTS805]

would like to work on this.

[GuTS805]

@david-allison Actually there is a little correction from my side. This doesn't actually reproduce through the normal Card Browser UI right now. CardBrowser (the activity) subscribes to ChangeManager itself and correctly re-searches on undo, so its masking the bug in practice.

the real gap is in CardBrowserViewModel itself, proven by a failing test. it never refreshes on its own, its only working because the activity happens to compensate. CardBrowserFragment.opExecuted() is actually dead code, nothing subscribes it.
So is this worth opening a PR or should I just close it.

[david-allison]

This doesn't actually reproduce through the normal Card Browser UI right now.

How did we get to this bug report + reproduction steps if it wasn't reachable via the UI?

Let's improve it now it's found

But I'll note that this is a setback: I want to be able to trust that when there are reproduction steps in a bug report, it has actually been reproduced.

[GuTS805]

@david-allison verified through the real CardBrowser activity now, you were right, it doesnt reproduce. wrote an activity level test this time, not just the viewmodel one, and it passes. CardBrowser's own ChangeManager subscription correctly refreshes the row list on undo.

so this isnt user visible right now. the viewmodel level gap is still real, that test still fails, but its fully masked by the activity doing the right thing.

given that, want me to close this, or should I keep it open as a low priority note since itd become an actual bug the moment CardBrowserFragment gets hosted somewhere without CardBrowser's compensating logic?

[GuTS805]

to reproduce the underlying gap directly

1. get a CardBrowserViewModel with 2 notes
2. select and delete one note
3. call tryUndo()
4. check viewModel.rowCount, its still 1 instead of going back to 2, even though the note is actually restored in the collection

test is at CardBrowserViewModelTest.kt, "undoing a delete restores the note but the browser row list is not refreshed", still failing on main right now

[david-allison]

Let's fix it, it may bite us later

[GuTS805]

@david-allison found something concrete while poking at this. reposition and refreshSearch() interacting badly seems to be a real, standalone bug. confirmed its independent of any subscriber logic too, just adding refreshSearch() right after repositionSelectedRows() with zero other changes breaks the existing "reposition in notes mode affects all cards 18307" test, an unselected card ends up repositioned when it shouldnt be touched at all.

pretty sure this is the same root cause behind the already ignored dataUpdatesAfterUndoReposition test in CardBrowserTest.kt, the one marked "doesnt work but should". havent figured out the exact mechanism yet, just that its reproducible and doesnt depend on my fix attempt at all. might be worth someone with more context on launchSearchForCards() taking a look, since it also blocks a clean fix for this issue

[david-allison]

@GuTS805 Remind me on the weekend, I won't have time this week