jtxBoard icon indicating copy to clipboard operation
jtxBoard copied to clipboard

[BUG] Task duplication when changing collections

Open johannesmono opened this issue 1 year ago • 5 comments

Describe the bug When adding a task and changing the collection, the current state of the tasks get saved to the previously selected collection. This also happens with an empty task.

To Reproduce

  1. Click the add task button and, optionally, fill out some data;
  2. change the collection, optionally finish data entry;
  3. save the task; and
  4. the created task appears as expected. Additionally a task, either empty or with "some data", appears in the previously selected collection.

Expected behavior No additional task is created.

Device and version

  • Android version: 13
  • jtx Board version: 2.07.06.gplay

johannesmono avatar May 05 '24 12:05 johannesmono

Having the same issue. This only seems to happen when switching from a remote collection to any other collection (local or remote).

lore-emu avatar May 07 '24 15:05 lore-emu

Thanks @johannesmono & @lore-emu , I have reproduced the issue and reviewed the code but it is not yet obvious, I need to continue debugging the issue. I'm just super busy those days, so please be patient.

patrickunterwegs avatar May 08 '24 20:05 patrickunterwegs

Sorry that it took a bit, I found the issue, it's really strange that this suddenly appeared as the part of the code didn't change. Still a small change was needed to make it work properly again, so probably it was a change in a library that caused it... I'll add the fix in the current beta which will be released soon.

patrickunterwegs avatar May 15 '24 20:05 patrickunterwegs

The bug seems to still be happening on the version that was just released (both on 2.7.7.ose and on 2.7.7.gplay). Is that expected?

lore-emu avatar May 22 '24 13:05 lore-emu

Hi, sorry, I checked it and it was solved for me, I will reopen this ticket and check again.

patrickunterwegs avatar May 22 '24 20:05 patrickunterwegs

Hi @johannesmono , sorry that this took I while, it was really a tough one. The problem was that the current entry was saved and moved in different coroutines. If the saving was completed after the moving, then the saving overwrote the logical deletion... But as those coroutines have their own priorities, it was pretty random which one was done first. That's why it was so hard to reproduce it.

However, I hope with the change it's fixed for good!

patrickunterwegs avatar May 27 '24 20:05 patrickunterwegs