Subtasks suddenly marked as not completed in batch after restart

[Gert-dev]

Describe the bug
Today when I started Planify, I suddenly got a bunch (10 or so) of 'overdue' tasks that have already been completed a few months ago, around August and September mostly. I did not do so manually and nothing else in the database reverted or went corrupt.

All the tasks in question were subtasks of the same parent task. I've had this occur once before and this was also the case then.

To Reproduce
I'm not sure exactly what triggered this, but I can explain what I did:

1. Have a parent task with a bunch of subtasks.
2. Mark most as completed.
3. Restart Planify (at some point in the future).
4. The tasks have been marked as undone.

Expected behavior
Subtasks that are done don't get marked as undone.

Desktop (please complete the following information):

• OS or DE: [e.g. pantheon, unity, gnome]: GNOME 47
• Version [e.g. 0.1.2]: 4.11.6

Additional context
Investigating the database, I see that all these subtasks in the Items table have had the completed_at field set back to empty, and checked is also now marked as 0. I still have a backup of my database from last week and they are all marked correctly with completed_at filled in and checked set to 1 there.

[Gert-dev]

I fixed the database by manually updating the fields again when this happened. Today (a few days later), however, this happened again with the same subtasks.

Trying to see now what might have triggered it; the only thing that happened yesterday before Planify itself was closed is that two subtasks (that are now also reopened) of the parent task were closed by me - some of them were due yesterday but none of them were due today. Looks like after a restart this triggered incorrect behaviour somehow, or perhaps closing Planify didn't correctly persist the state.

I don't recall if I manually closed Planify or if it was closed along with shutting down my computer, so perhaps the different type of termination can result in state being lost? Though then I wouldn't expect sibling tasks to be reopened, just the closing to be lost.

EDIT: The updated_at field was not updated for these tasks either despite them having been modified, in case it helps identify the code path that was taken.

Weirdly enough there was one subtask I closed yesterday that did not get reopened, despite two others being so (as well as ones that were closed months ago).