Anki-android: cloze increment are quietly added to the wrong deck, can be extremely problematic

[thiswillbeyourgithub]

Reproduction Steps

1. when reviewing, edit a cloze
2. incremnt a cloze manuallly, that means like in desktop by turning a cx into cx+1 (*I don't know if it also happens when using the "cloze deletion" select button) ((to be more clear : say you have a note with c1 c2 c3 c3 c3, you turn one c3 into a c4))
3. the new note will be added but ends up in another deck. I don't know the logic behing which deck it goes into.

Expected Result

The new note should go to the right deck

Actual Result

The new note ends up in a seemingly random deck

This bug is IMO of high priority as there are no ways for the user to know that it happened. If the user has not set tags for this note he could have a very hard time to find where it ended up. And as the new note has the same creation date as the original one (I think?) it means you can't really find it without tags or by note type.

In my case, that meant that my exam related cloze was added somewhere in my gigantic spanish shared deck, had I not understood what happenned, I could have screwed up quite a lot.

A friend of mine confirmed that the issue happened on her ankidroid too.

Debug info

AnkiDroid Version = 2.14.1
Android Version = 9
ACRA UUID = 665666ae-6d44-4276-9d91-4d0b78412437
Scheduler = std2

Research

• [ x ] I have read the support page and am reporting a bug or enhancement request specific to AnkiDroid
• [ x ] I have checked the manual and the FAQ and could not find a solution to my issue
• [ x ] I have searched for similar existing issues here and on the user forum
• [ ] (Optional) I have confirmed the issue is not resolved in the latest alpha release (instructions)

[david-allison-1]

Thanks for the report. Is this a regression in 2.14, or did this occur in 2.13?

Relevant code:

https://github.com/ankidroid/Anki-Android/blob/50ff61b7737d2b265e41d24d3a67f511957d6f56/AnkiDroid/src/main/java/com/ichi2/anki/AbstractFlashcardViewer.java#L1123-L1132

Using the reference (sEditorCard):

https://github.com/ankidroid/Anki-Android/blob/36245c61114580117650299a2da114da96819b72/AnkiDroid/src/main/java/com/ichi2/anki/NoteEditor.java#L508-L515

[david-allison-1]

@thiswillbeyourgithub Does this occur on Anki Desktop? Do the cards appear in different decks?

Relevant code:

https://github.com/ankidroid/Anki-Android/blob/6c4702de766fdc2a2f41f01a879503d2dc584e49/AnkiDroid/src/main/java/com/ichi2/libanki/Collection.java#L810-L822

[thiswillbeyourgithub]

Hi, thanks for the quick reply.

I never noticed this on desktop and I use this a lot so I don't think it happens there.

I'm positive this happened on 2.14.0 I just asked my friend if she noticed this in 2.13 but I don't know when she'll answer sorry

[david-allison-1]

No worries. I'm likely going to need concrete reproduction steps with a test deck to take this further.

I think this is likely caused by two cloze cards being in different decks, but if this isn't the case, I'll get on it ASAP.

[rwmpelstilzchen]

A similar problem happens to me as well. I don’t use Anki’s built-in cloze deletion mechanism, but Cloze Anything. It uses Anki’s selective card generation feature in order to create cards for the cloze deletions (see the instructions):

{{#ExpressionCloze}}
{{#ExpressionCloze1}}
HTML+JS goes here
{{/ExpressionCloze1}}
{{/ExpressionCloze}}

Since 2.14.0 when I edit a cloze deletion field in order to create a new cloze deletion card (for example, changing ((c1::Hello, world!)) to ((c1::Hello,)) ((c2::world!)) and changing ExpressionCloze2 from an empty string to 1) the new card may end up in the wrong deck. I noticed it when some new cards that were made this way appeared in the default deck (which is usually empty, hence invisible), making it shown in the deck list. I upgraded to 2.14.1 in hope for a fix, but the problems persists. I’m quite sure this didn’t occur in 2.13, since I made a lot of such cloze deletion cards using 2.13 over a period of time and they all seem to be in place.

Looking at the changelog, the line Card Browser: Adding cards defaults to selected deck might have to do with this.

If you want any additional information so you can solve this bug, I will be happy to provide it.
I agree with @thiswillbeyourgithub: this is extremely problematic because it happens quietly, without the user knowing their cards are scattered in the wrong decks.

[david-allison-1]

Having a sample deck which can reproduce this problem would be very helpful. GitHub accepts zip uploads, or this can be emailed to me at my gmail: davidallisongithub.

Card Browser: Adding cards defaults to selected deck was only for the "Add" functionality, and did not touch the code of the note editor.

[rwmpelstilzchen]

Thanks! I will try to make a minimal scenario in which the problem is reproducible.

@thiswillbeyourgithub, would you like to do so as well for your problem with the built-in cloze deletion mechanism, in case the particularities are different?

[david-allison-1]

Thanks for the confirmation, reproduced no more action necessary.

Cause (I believe): 554ce84211efc17b8503acf45be600497f873d47

[david-allison-1]

Confirmed: 554ce84

git bisect reset
git bisect start
git bisect bad
git bisect good 18c7cde8ab8655b7ea4854884f7d979c53dd57f1
git bisect run ./gradlew AnkiDroid:testDebug --tests "*editClozeGenerateCardTest*"

----

dd4ba470ed3b228cb64087469008ff0266e69d98 is the first bad commit
commit dd4ba470ed3b228cb64087469008ff0266e69d98
Author: Redacted
Date:   Fri Oct 23 16:29:04 2020 +0200

    NF: avoid multiple conversions to Long

 .../src/main/java/com/ichi2/libanki/Collection.java      | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)
bisect run success

Note to self: add bisect instructions for Windows to the Development Guide - keep on forgetting the syntax

[rwmpelstilzchen]

Thank you so much for the quick fix! 🙂🎉

I cannot compile and check it at the moment.

So the difference between the types (Long vs. long), introduced by this commit, led dids.get(nid) != did to be true while in fact it should not have been; do I understand this correctly?

[david-allison-1]

Thank you so much for the quick fix! 🙂🎉

I cannot compile and check it at the moment.

So the difference between the types (Long vs. long), introduced by this commit, led dids.get(nid) != did to be true while in fact it should not have been; do I understand this correctly?

Yep - we'll get an alpha out soon.

Here's the data in a debugger before the fix