"Last sync was incomplete" message, synchronization via WebDAV not possible #3641
Comments
|
Thank you very much for opening up this issue! I am currently a bit overwhelmed by the many requests that arrive each week, so please forgive me, if I fail to respond personally. I am still very likely to at least skim read your request and I'll probably try to fix all (real) bugs if possible and I will likely review every single PR being made (please, give me a heads up if you intent to do so) and I will try to work on popular requests (please upvote via thumbs up on the original issue) whenever possible, but trying to respond to every single issue over the last years has been kind of draining and I need to adjust my approach for this project to remain fun for me and to make any progress with actually coding new stuff. Thanks for your understanding! |
|
I got it to work (for now, kind of): Is this maybe the recommended way to set up a new machine anyway? The bug I describe however also existed before - those two machines did synchronize successfully at some point, and only started showing the sync issue at some point in the past (probably with some update to superproductivity on one or the other side). So me starting over on the one machine was just a way to try and get the sync to work again. Having to do this export-import stuff for setting up feels a bit strange. For me the most logical way would have been (as I tried) to just point the sync to the same settings and fetch the remote state for a fresh install, but this does not seem not to work (though I suppose it should?)! Just speculating, but from my experiences in this issue, it seems like for the sync to work, two superproductivity instances need a somewhat nebulous "common understanding" of their state; if the two machines somehow loose this "common understanding", then the sync stops working; therefore they need to be "re-acquainted" (by exporting the state of one, and importing it into the other). Hopefully it was just some temporary glitch, and it works from here on out... I'll try and set up superproductivity sync on a completely fresh machine and see what happens there! |
|
I was also running into this issue when setting up super-productivity on multiple devices. Similarly, my workaround was exporting/importing the data to get sync properly set up, after this initial weirdness, syncing worked just fine. I also noticed that I was able to get one of my devices properly synced up by pressing the |
|
After working a while on the previously "problematic" machine (after the "fix" via the export/import workaround described above, and while superproductivity was not running on the previously "good" machine); I now get the "Last sync was incomplete" message on the previously "good" machine. On the first start of superproductivity there, I just got the "Last sync was incomplete" message; I exited the dialog to backup the local data; then disabling and re-enabling sync lead to the "conflict" dialog (where I chose "keep remote"), followed by the "last sync was incomplete" dialog... I then tried the "force upload" button now as proposed by @MonsterDruide1 above, and indeed it seems like the data produced by the remote machine seems to stay available. So the sync actually seems to work properly, only the "last sync was incomplete" dialog is shown erroneously? |
The message is potentially misleading. Super Productivity expects the rev returned from the server to be consistent. In the screenshot you posted it is almost the same, but there is |
How is this rev string determined on the server / in superproductivity (it's the etag header, right)? I don't really have an idea where such a -gzip suffix could come from, specifically for my server configuration - it's just a normal nextcloud setup I think? EDIT: But yeah from everything I've read, apache appends the -gzip to the etag whenever it is transport-compressing; see e.g. here; not sure whether this is something standardized... seems I could configure apache to not append the |
|
Thanks for digging into this! I think in this case its safe, to just remove the string from the etag value whenever it is present from Super Productvity's side of things. I'll provide a fix soon! |
I have searched for similar issues, but haven't found one exactly describing my issue:
Your Environment
Expected Behavior
I can synchronize the superproductivity state between two machines.
Current Behavior
On the "problematic" machine, triggering the sync causes this message to show up (at least it does now after a fresh install/ cleaning of all superproductivity data):
When I press "Keep remote", I get this message:
As superproductivity seems unable to read the data it loaded, there is no way to continue sync...
Steps to Reproduce (for bugs)
For the "problematic" machine where the bug happens:
Can you reproduce this reliably?
This happens every time I try to sync from this one machine (sync on the "good" machine seems to work fine, at least there's no error messages there, and the data on the server seems valid json).
I even tried to completely remove (uninstall + remove any files in AppData/Roaming/superProductivity); when setting the sync up again -> exactly same issue.
I have tried with compression on and off; and even though the served file only looks like as shown in the console log with compression turned on, in super-productivity, I see the strange letters on the "problematic" machine no matter whether compression is turned on or off. I have verified that the MAIN.json file on the server actually contains readable text instead of the gibberish shown in the log, when compression is turned off and sync is triggered on the "working" machine.
Maybe some transfer compression gets in the way? But why then does this only happen on one machine?
I don't think it makes a difference but the problematic machine is in the same network as the server, while the machine where it works is remote.
Console Output
(the "dataInStr" line is shortened, it just continues on with chinese letters...)
The text was updated successfully, but these errors were encountered: