Regression and overwriting of newer data

[working-name]

Hi there,

I was wondering if you have any insight into what may have happened, and if you keep a log of changes in the database.

I made a lot of changes, including to the note type days ago, but had not turned on auto-approve changes. I then had to manually accept changes in the front end. I figured go from the oldest entry to the newest, aka makes changes in the same order. I didn't notice anything odd until hours later, when my friend who is a maintainer could not "see" my changes. So we tried to check for new content, no updates. Finally gave up and unsubscribed, removed the deck, and re-subscribed. That's when things became weird and I noticed the data loss - but it doesn't mean that's what triggered the data loss.

So now I'm trying to see what else is stored in the database that might clue me into what happened and how I can fix this bug. Hindsight is always 20/20, of course, but I guess I now how to automate database dumps every hour rather than day...

[working-name]

Update: ok found the log of changes in the db. For some reason it decided to accept older changes the other person made and overwrote newer changes I made, to the same decks. It also deleted a bunch of cards. What's even more weird is that it overwrote the whole notetype (css and template), with an older version.

That, in my opinion, should not happen. User should be prompted to confirm they want to overwrite newer changes, or even better, keep changes made in the last week so one can easily revert if there's issues. Might be a huge code burden.

[CravingCrates]

Hey there,

First and foremost: every time you pull, a backup is created. Please restore from that backup to roll back and avoid data loss.

Edits:
From your description, I’m not entirely sure what may have happened.
Outstanding suggestions are always compared to the current live version of a field, not to the version that existed when the suggestion was created.
For example:

• You have a field Version A.
• You suggest Version B.
• Later, you suggest Version C.
  If you approve Version C, the field will contain C.
  If you then approve B, it will overwrite C with B.
  When you pull changes, notes get overwritten with this content, which can overwrite local edits you made in the meantime. Is that what you mean by the system overwriting newer changes?

To prevent local overwrites, you can add the AddCollab_Protect:: tag to a note. That will ensure the system does not touch the specified field.

Automatically "ignoring" cards that changed locally is a slippery slope. I'd have to check every single field manually and can't just make assumptions about the user not wanting updates for this one note. Say a user fixes a typo in a note, and somebody else a major content error on it. I doubt the user would want to ignroe the content error fix for the sake of keeping their grammar error untouched. It's a very constructed example, but I hope you get the gist. It's not my call to make and automating it or finding a general solution that makes sense on a broader scale, is very diffiult, hence the manual protection requirement.

Card Deletions:
The system cannot delete cards on its own as far as I know. If there’s a bug causing this, it would be significant. In three years I haven’t seen it happen, so I’d appreciate any additional details you can share.

Notetype:
The system always forces a sync of the notetype to match the server version. This means your local notetype is overwritten on sync.
You could argue it’s only necessary to enforce field compatibility rather than template consistency, but for now I overwrite both to avoid drift.
However, you can edit templates and CSS on the website. Could you try that and let me know if it works for you?

I was planning on making a better changelog history tracking in the database which could alos be utilized as a kind of commit history to track changes, but haven't gotten to that yet. I feel like that's what you're looking for. Unfortunately, it doesn't exist at the moment.

I appreciate your report-it doesn’t go unnoticed. To properly triage this, I’d need a bit more information.
I’m usually more responsive on Discord, where it’s easier to discuss these issues in detail. If that’s an option, feel free to reach out.