landed in an un-syncable state

[dixitk13]

Was trying out this app for the first time, made like a test thingy in my local machine. Took the docker-compose file from #7 and it worked well for a while. The locally kept files synced with the docker ones, persisted between restarts as well. But after a few changes, seems like I landed in this un-syncable state where I've lost a few set of rows & this doesn't sync anymore.

Exporting and importing doesn't work as well. Any suggestions?

actual-sync-issue.mov

Note: This has nothing to do w/ the PR - I just wanted to clarify I used it NOT from master.

[SlothCroissant]

I had the same issue - opening the app in an incognito/private session (so it didn't use the cache, etc) fixed it and things looked good for me. Since it all was good, I just cleared cache/cookies on my non-incognito window and re-opened Actual's web UI and logged back in. Once done, I was all set to go again.

[dixitk13]

@SlothCroissant, you're right! Clearing the indexed db for actually get rid of the error at least, but I've do have lost considerable amount of entries, not sure where the sync messed up for me 😭

[dixitk13]

So, I cp-ed some of the older timestamped backups to db.sqlite to see if I could recover my lost data, but that didn't work.

Just wanna not lose this again - does anyone know which files to safely to store so it behaves like a backup all the time?

ls -l user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/*
-rw-r--r--  1 me  staff  389120 May  1 16:46 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/cache.sqlite
-rw-rw-rw-  1 me  staff  380928 May  1 16:46 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/db.sqlite
-rw-r--r--  1 me  staff  380928 May  1 16:39 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/db.sqlite.bk
-rw-rw-rw-  1 me  staff     480 May  1 16:41 user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/metadata.json

user-files/110d687f-4db8-4d3f-b9c6-d87652e8c25a/backups:
total 2232
-rw-r--r--  1 me  staff  380928 May  1 14:52 29213a23-b484-42c1-957b-296efdd06e36.sqlite
-rw-r--r--  1 me  staff  380928 May  1 16:35 54228c6a-1a17-479e-bcfa-e0777848d691.sqlite
-rw-r--r--  1 me  staff  380928 May  1 15:07 f06437b8-1da3-47a2-bad5-15745d2a922d.sqlite

[andreathniah]

I've landed myself into the same state as @dixitk13 so I am very interested in the recovery process too 👀

[jlongster]

Hmm. The desktop app has automatic backups. That's what is nice about the desktop app -- it's all just normal files so that's easy to do.

Backups on the server is very new and not super well-tested.

This version of the server is also not as well-tested as the closed source one. I would LOVE any help debugging this. If you are a developer and in this state, can you help?

Resetting sync should always work. What it does is call this method to upload a "user file": https://github.com/actualbudget/actual-server/blob/master/app-sync.js#L226

That overwrite the "base" version of your file on the server and creates a new "sync group". From then on, you can start syncing again. It's basically a "fresh start" when it comes to syncing and should fix any problems. Had no problem with this in the closed-source server.

I would add some logging in that method and see what's happening. Any errors in the console? Any errors in the server? etc

[jlongster]

OH, I'm pretty sure I know what this is. Also see:

#15

This is all due to the server not serving the app with the right headers. It's not enabling SharedArrayBuffer so it's using an old really unstable code path. I'll look into this soon

[jlongster]

Particularly #23 (comment)

[rich-howell]

Hey @dixitk13

This should be fixed in version 20.10.25 which is our latest version. If you still have issues with this, let me know and I will re-open your issue.

Cheers
Rich