On a brand new Linux box installed Weave 0.1.26, I attempted to do an initial (local) synch down by wiping out the client data in order to replace it from the server. When I try to synch after telling it to wipe out the local data, I receive the following: 2008-03-29 21:37:47 Service.Main INFO Weave Sync Service Initializing 2008-03-29 21:37:47 Service.Main INFO Weave scheduler enabled 2008-03-29 21:37:47 Service.Main INFO Using server URL: https://services.mozilla.com/user/dfba9baf82ab25da08625aa27370c44fb46cdf5a/ 2008-03-29 21:37:47 Service.DAV INFO Logging in 2008-03-29 21:37:48 Chrome.Window INFO Login successful 2008-03-29 21:38:04 Service.BmkEngine INFO Beginning sync 2008-03-29 21:38:04 Service.BmkEngine INFO Got status file from server 2008-03-29 21:38:04 Service.BmkEngine INFO Remote/local sync GUIDs do not match. Forcing initial sync. 2008-03-29 21:38:04 Service.BmkEngine INFO Downloading server snapshot 2008-03-29 21:38:05 Service.BmkEngine INFO Downloading server deltas 2008-03-29 21:38:06 Async.Generator ERROR Exception caught in WeaveSync__sync: TypeError: this._data[command.GUID] is undefined Linux box is running Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b4) Gecko/2008031317 Firefox/3.0b4.
This seems like some variant of the previous issue that we had.
I've been debugging this one for a couple of days (thanks for filing the bug though). I think I'm close to finding the problem. I've found several bugs in the process!
Cc'ing iav, who has been working hard with me to repro this.
I think I understand what happened here. The basic problem is that the server contains an 'edit' command for an item that is not in the local snapshot. However, the "real" cause of the problem is of course that the local snapshot does not accurately reflect the server state at the time it was saved. I fixed two bugs that would cause an exception to be raised in the reconciler: * the 'likeness' comparator for bookmarks was buggy and was trying to access an undefined property. * if we found two 'like' commands (two creates with different guids but for the same item), then we would incorrectly assume all other commands had a data payload. This is incorrect when there are remove commands in the mix, as those do not have that. Now, the reconciler had a try/catch block around it, and in the case of an exception would return an empty list of commands for both the server and the client: that is, "do nothing". The sync engine, which calls the reconciler, (correctly) considers empty lists to mean that there is nothing to do. Since there were commands before reconciling, that means that the local snapshot should be updated, so it does so. Thus: whenever the reconciler had an internal exception, you'd end up with an incorrect local snapshot, which reflects client state but *not* server state. I am removing the try/catch block in the reconciler. This will cause the exception to bubble up to the engine and simply stop execution at that point, which is better than saving a bad snapshot and having an error later.
(In reply to comment #4) > I think I understand what happened here. The basic problem is that the server > contains an 'edit' command for an item that is not in the local snapshot. > However, the "real" cause of the problem is of course that the local snapshot > does not accurately reflect the server state at the time it was saved. Well, the local snapshot, in this instance, is nothing. I told it to wipe client data as it is a brand new profile and I didn't want to synch up the default Firefox bookmarks but to synch down my stored Weave profile bookmarks and history. So I wiped the local data with the command in Weave and then told it to synch.
Hmm then it sounds like what you are seeing is a different variant of the bug. If your snapshot is really nothing then I think either a) your sever snapshot is not consistent with the server deltas, or b) your client is confused about which version it's currently at, so it is trying to apply the wrong set of deltas. Can you reproduce this bug reliably? Do you have steps I can follow to get it with a minimal bookmarks set (e.g., just 2 or 3 bookmarks)? Or hop onto #labs, I'll be working on this bug...
I don't know about reproducing it. I'll have to dig out the laptop at home after installing 0.1.27. Unfortunately, I only have my work laptop when I'm onsite at Mozilla.
The easiest way to reproduce sync errors is by using multiple profiles on the same machine. Minimal test cases (as few items as possible; as few operations/sync runs as possible) make it much easier to figure out the real problems. Sync problems can have side-effects down the road (in future sync runs), so errors (such as this 'this._data[command.GUID] is undefined' one) are difficult to debug without knowing the full state/command history. That said, I did find a couple of problems after a 'reset server data'. It is important to restart all instances of Firefox (on all machines) after resetting server data.
Is this problem still reproducible? I am not able to get this error myself.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
Changing resolution to fixed, I did fix a bunch of cases where this error could happen.
Resolution: WORKSFORME → FIXED
I don't see it anymore so it is all good.
Status: RESOLVED → VERIFIED
Component: Weave → General
Product: Mozilla Labs → Weave
Target Milestone: -- → ---
You need to log in before you can comment on or make changes to this bug.