Their phone syncs, and - for whatever reason - touches the record on the server again. Imagine that a user adds a bunch of bookmarks to their toolbar. Thirdly, is Sync on desktop uploading records with the correct children array?įourthly, is Fennec preserving the positions of records? Secondly, is it using the same method to indicate position changes as we are on Android? (There's a 'pos' attribute to a record, and the children array on the parent.) I haven't explored this possibility yet, but it seems promising.įirstly, is desktop propagating position changes when they occur?

We'll finish the download, and then we'll upload our own computed records, with our own computed positions. But during the reconciling stage it will see that the local record was modified _later_ - it made it to the database! - and won't apply the incoming record. If it tries a sync again, it will re-download records, because our timestamp is still 0. More importantly, it either won't reach a repositioning stage, or will have to handle partial data when it does. If Android Sync fails to finish storing records - some exception is thrown, or we're killed with OOM, or whatever - it will have a sample of records from the other device. The server will also return them in an arbitrary order - *probably* with folders first, but who knows? Walking the dog, five further late-night unvetted possibilities came to mind.ĭesktop uploads bookmark records in an arbitrary order. Is to leave folders until last, walking them leaf-to-trunk, but that imposes the maximal amount of churn on other clients (every record has to be applied then moved).Īnother mitigation is to ensure that records are proximal to their folders, so they have more chance of hitting the server together.

Probably the most partial-safe order for: Mitigation: have desktop upload records in a strict partial-safe order. If the other device is Fennec Native, you'll see possible reordering in either case. * Modify the partial folder on other device Oh, and a difference in behavior between Android and desktop: when desktop sees partial data, it computes a new order locally, but - as far as I can tell - doesn't reupload a reordered folder unless something else changes (add or remove a child locally).Īndroid does its best to ensure that the local and remote data are identical, so when it modifies a folder (including its child array) it uploads the modified record.

Rollback mozilla firefox 41.0.2