On 31 May 2018 at 10:22, Mark Hammond <mhamm...@mozilla.com> wrote: > On 31/05/2018 9:28 am, Ryan Kelly wrote: > >> >> My summary of this thread: >> >> 1) Rebooting with no further intervention is safe; it will lose synced >> tabs data until each device uploads a new tab bundle, but otherwise sync >> will work as normal. >> 2) We might be able hasten the re-upload of synced tabs by fiddling with >> the syncIDs in /meta/global, but it's not clear that's worth the hassle or >> the risk of accidental bustage. >> > > I think my last comment on this was missing another subtlety - for a > desktop device that's running when this reboot happens, the device will > re-upload tabs on the next sync if there have been changes made to tabs on > that device. > > IOW, if that device is being actively used (ie, opening new tabs or > switching current tabs), the longest you'd need to wait for the tabs to be > uploaded is 10 minutes. >
Right, the failure case here would be something like "I left some tabs open on my work computer, and now I want to access them from home", where the work computer might be switched off or inactive with no reason to restore its synced tabs. Ryan If the device is *not* being actively used then it will take a restart (or > for the user to start interacting with tabs on it) before tabs are > uploaded. We could probably mitigate this in the clients too - eg, I could > imagine tabs checking, on every Sync, whether a record with its ID still > exists on the server and uploading otherwise. This is an extra network > request per sync, but the response would be tiny so the overhead is > relatively low (ie, much lower than uploading all tabs each sync) > > I'm inclined to think that's also a bit of overkill given things will > recover in a timely manner if the device is active, but it's worth > considering if product considers this a show-stopper. > > 3) Restoring to an earlier point in time is, as usual, a great way to >> confuse clients and risk data loss, so let's table that broader discussion >> for now and focus just on rebooting nodes with their DB intact. >> >> If accurate, I think the next step here is to get product sign-off on >> whether the temporary tab loss in (1) is acceptable, and if so, proceed >> with a live test to confirm the behaviour in stage. A mini sync-fest might >> be a good way to test that out and discover any other lurking weirdness. >> > > Sounds great! > > Mark > _______________________________________________ > Sync-dev mailing list > Sync-dev@mozilla.org > https://mail.mozilla.org/listinfo/sync-dev >
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
