fraidycat icon indicating copy to clipboard operation
fraidycat copied to clipboard

Sync does not handle deletes in a sensible way

Open andrew-wja opened this issue 3 years ago • 9 comments

  • [x ] I have checked the Common Problems page.
  • [ x] I have searched the issue tracker for a bug that matches the one I want to file, without success.

Desktop (please complete the following information):

  • OS: Linux
  • Browser Firefox
  • Version [No idea where to find this, I expect it to be visible somewhere after clicking on the settings gear but it isn't]

Describe the bug If I delete some follows in browser instance A on Linux (for example, Mac and Windows behave the same), and sync (manually force a sync now in Firefox -> Account -> Sync Now), then later, when I open browser instance B on Mac / Windows / Linux (substitute as appropriate depending on the choice made for browser instance A) the deleted items have reappeared. I need to delete them from all individual browser instances and every platform.

This doesn't happen when I add a follow -- it appears in each browser instance properly. It seems as if either removals are not being synchronised, or that there is some logic that, when I open a browser instance, causes the extension to begin synchronising the follows it currently knows about before the browser sync has time to update the list of follows.

andrew-wja avatar Mar 23 '21 17:03 andrew-wja

Deletes do get synced - and they should be working like you say. (Work for me fine in Vivaldi.) But something is up - need to investigate.

Thanks for the report!

kickscondor avatar Mar 25 '21 21:03 kickscondor

I tried this again and it seems to be happening pretty reliably! The specific scenario I'm experiencing is that I delete some follows from fraidycat in firefox on linux, and when I open firefox on mac, they all get added back. The same thing happens if I delete them in firefox on windows (same version of firefox in all 3 OSes).

I will try to complete the test matrix of delete on platform A, next open browser on platform B and see if there is a combination that doesn't exhibit this behaviour. It seems as though each instance is taking the union of the local state the last time the browser was open and the sync state, instead of just using the sync state, but this may be how Firefox sync works as opposed to anything fraidycat is doing.

andrew-wja avatar Mar 29 '21 11:03 andrew-wja

So I had a bit of a deeper look, and it does indeed seem that fraidycat in firefox on Mac is behaving strangely. Deleted items show up in the JSON with a subfield like {"deleted":true,"editedAt":"2021-03-30T10:49:55.702Z"}. When I open firefox on Mac and it syncs the extension, if I dump the JSON again, those subfields have been stripped out. I have no idea whether they are synced and then removed or just not synced, but the effect is the same either way. Given that just adding a new follow is working fine, I would guess that it's not a sync problem but something to do with how fraidycat processes updates to the follows.

andrew-wja avatar Mar 30 '21 11:03 andrew-wja

I submitted a fix to this yesterday - give it another try in Firefox.

kickscondor avatar Apr 07 '21 14:04 kickscondor

Unfortunately the problem persists. When I open firefox on mac, and "sync now", fraidycat re-adds all the deleted follows and I see them pop back in in real-time in another firefox instance on linux

andrew-wja avatar Apr 09 '21 10:04 andrew-wja

Hi, I had a bit of spare time this week so I had a look at the code, and I think I see the problem here: https://github.com/kickscondor/fraidycat/blob/master/src/js/storage.js#L585-L600

If inc.follows[id] exists but findFeed() fails, the incoming follow from sync is not in the local set of follows. However, looking at the logic further down, there is an if (current) guarding the deletion logic inside an if (!current). At line 591, the incoming follow gets added to the local follows if it has a url field. Then at line 593, if !current which is true in this case, if incoming.deleted, the follow is added to the local follows -- I guress this is so the deleted field can get checked and handled later.

However, the next if statement is an if (current) which cannot be true inside if (!current), so the actual deletion code at 596-599 does not execute.

andrew-wja avatar Apr 11 '21 12:04 andrew-wja

I think this should fix it: https://github.com/kickscondor/fraidycat/pull/216

andrew-wja avatar Apr 11 '21 12:04 andrew-wja

Ok - this fix is merged. Out for Firefox right now - Chrome in a few days.

kickscondor avatar May 04 '21 05:05 kickscondor

Hi, passing through by chance: Can this be closed?

runiq avatar Sep 01 '22 07:09 runiq