[BUG] Recurring tasks keep coming back despite them being done

[kalsan]

Describe the bug

I'm using JtxBoard together with DAVx⁵ and a Radicale server, to which a Thunderbird instance is connected. I have two recurring tasks, one due weekly and another monthly. I've set the JTX filters such that it shall display:

• hide completed tasks
• start must either be in the past, today, or blank

Every week, I get the weekly task and mark it as completed, after which it disappears, same for monthly. However, after a random amount of time, typically 4-8 weeks, ALL of the instances of one of the recurring tasks suddenly come back (no longer marked as completed). 1-2 weeks later, the same happens on the other task. This happens when synchronizing with the dav server.

To resolve it, I can mark each instance of the recurring task as completed again (which is painful since there are so many) or delete JtxBoard's data and set up JtxBoard from scratch again (equally painful).

I know this is a JtxBoard caused bug, because resetting it helps; and Thunderbird, which syncs the tasks bi-directionally with JtxBoard, is not affected.

To Reproduce

1. Set up a recurring task as described above, including filtering and syncing
2. Wait 4-8 weeks, marking task instances as completed on the day they are due
3. Suddenly all of them come back

Expected behavior

Completed task instances should stay completed

Screenshots

Device and version

• Device: Pixel 7a
• Android version: Graphene OS (Android 16)
• jtx Board version: 2.14.00.ose (214000003)
• Downloaded from: F-Droid

[kalsan]

Additional note: DAVx⁵ is configured to only sync events back to 90 days into the past. The recurring tasks shown here are older than this. Maybe this is linked.

[patrickunterwegs]

Hi @kalsan , I would still need to reproduce the problem, but it's likely that it's the following: When a recurring entry is synchronized, jtx Board receives a file with the entries that contains an entry that defined the recurrence and then additionally all recurrences that are not exact recurrences of the original (e.g. have been marked as done). So jtx Board creates the entries based on the recurrence rule and applies the changes of instances that have been delivered.

In your case it's likely that the server filters out these change recurrences that are older than 90 days, so jtx Board doesn't know if the recurrence is missing because it's not relevant (it's just a regular recurrence) or if it was filtered out by the sync, so jtx Board just recreates these entries.

You can do the experiment and sync events in DAVx5 further back and see if the completed entries re-appear properly marked as done.

If yes, then I'm afraid there's not much I can do here, as - as I mentioned before - jtx Board needs all information about the recurring entries.

[kalsan]

Servus @patrickunterwegs

Thanks a lot for your helpful thoughts :-)

Considering how you describe the workings of recurring tasks, it's indeed likely that DAVx⁵'s cutoff is the reason for this. At first glance, it seems like a problem that's difficult to solve, as the DAV standard is fixed and DAVx⁵ needs to cutoff to remain performant. Excluding non-terminated recurring tasks from the cutoff would be a hacky solution, considering DAVx⁵ is somewhat content- and backend-agnostic.

However I think there's something Jtx Board can do to handle this. And Jtx would also be the perfect candidate to do so, as it is to my knowledge the only FOSS Android app out there that handles recurring tasks properly at all (Tasks.org's way to deal with them is not nearly as useful as Jtx's). Here's the sketch of the idea - unfortunately I'm not an Android developer, so I'll need to stick to concepts:

Jtx Board could track recurring tasks in its internal app database, storing a copy of every non-terminated recurring task along with the details. When the DAVx⁵ cutoff occurs, Jtx board could notice that a task has gone missing and anotherone has shown up. Assuming that tasks have IDs and the cutoff preserves these, all Jtx would have to do would be to move the start date of the recurring task in its cache to that of the new first occurence reported by DAVx⁵ and to update the task according to the that first occurence.

This would likely work very reliably, as DAVx⁵'s default is to have the cutoff 90 days into the past, so the new first instance of the recurring task would be marked as completed already.

What are your thoughts on this idea?

Best, Kalsan

[kalsan]

@patrickunterwegs the problem occured again today and I experimented by setting DAVx⁵'s cutoff to a higher value. This did not fix the problem. This doesn't have to mean the thoughts above are wrong, but it might give further info on DAVx⁵'s inner workings.