480057 - Provide a way for users to "reset" their sync

Status: RESOLVED FIXED

(Cloud Services :: General, defect)

Description

[Dan Mills [:thunder]]

There are cases when unexpected errors cause problems for users (e.g., duplicate items, or some items don't sync, etc).  However, users currently have no recourse--there is nothing they can do in Weave to fix their problem.

We need UI to allow users to do three things with each individual data type (or all of them):

1) Do a "full sync".  That is, instead of looking only at new/changed items, download all server data and run a full comparison.

2) Wipe this client and download server data.

3) Wipe the server and upload current server data.

The easiest is the first, simply resetting the lastSync pref and any local file caches will do the trick.

The second requires that we wipe all client data, potentially a dangerous operation, but shouldn't be too hard.

The last is the trickiest; we also need to cause all other clients to do a local wipe (or they would re-upload to the server the stuff you wanted to delete in the first place)

Comment 1

[Ed Lee :Mardak]

So for wipe #2 we should just tell each engine to .wipe().. and additionally reset lastSync?

As discussed for wipe #3, we would make a new syncID for /meta/global. Additionally we create a new attribute for /meta/global "wiped" and its value is a hash of engine names that need to be wiped being the key and the value is an array of client GUIDs that have wiped that engine.

/meta/global = {
  syncID: "a new sync id",
  wiped: {
    bookmarks: [ "client1 guid" ],
    tabs: [ "client1 guid", "client2 guid" ],
  },
}

The client initiating wipe #3 will only add keys to the wiped hash if it needs to be wiped and initialize it with an array of 1 item containing its own guid. As other clients sync with the server, they check if there's a wiped hash and iterate through each engine name to see if it's not yet in the array. If it isn't there yet, it adds itself and tells the engine to wipe.

One caveat is that new wipe #3s will need to preserve existing wiped key/value entries if it *isn't* wiping that data because a client might be late to the party. If the new wipe #3 *is* wiping the data, it'll just set the array to [ "self guid" ] as usual.

So when do we get rid of the wiped value or just set it to {}? When syncID gets changed *not* through wipe #3? That might cause some clients to not wipe when it should have. ??

Comment 2

[Dan Mills [:thunder]]

I think engines selectively implement wipe() as sometimes deleting local files (e.g., tab store does this), and sometimes deleting local data (e.g., bookmarks store).  You should probably have two separate calls instead, like a reset() vs wipe().  reset() would delete any local files and also reset lastSync.

For #3, I can see some problems with the approach we discussed.  One is that changing the syncID causes a full 2-way re-sync of all engines, so you'd be doing that as a by-product of wiping one collection.  Another problem is what happens if you add a new client into the mix, you don't want it wiping anything in that case.

Let's think about it a bit tomorrow.  Maybe part of the solution is to generate a guid for each collection at creation time--morph syncID into a hash like this:

{
  storageVersion: "0.2.100",
  syncID: {bookmarks: "some id",
           tabs: "another id"}
}

Then use the clients collection to cause currently-known clients to wipe data locally.  Each client keeps a record on the server like:

{name: "Main Profile", type": "laptop"}

We could extend this to have instructions, something like:

{
 name: "Main Profile",
 type: "laptop",
 instructions: [{action: "wipe-collection", collection: "bookmarks"}]
}

So if you wanted to cause other clients to wipe, you'd alter their client records accordingly.  We could have different action types, like wipe-collection, wipe-all, force-resync, etc.

That would also allow us to construct a control panel for your other clients, which we do want but is orthogonal to this bug.

Comment 3

[Dan Mills [:thunder]]

[
  {action: "wipe", args: [["bookmarks"]]},
  {action: "reset", args: [["tabs"]]},
  {action: "fullWipe"}
]

Comment 4

[Ed Lee :Mardak]

In terms of exposing this functionality to the user..

Data pane: "Sync Now..." button to force a hard refresh? This is assuming that the user has come along to this page because something wasn't working?

Clients pane: Next to each client, we could have a wipe button where we would set a wipe action for a client and next time that client syncs, it'll wipe itself causing a resync.

Or maybe a "make client like server copy" which does the remote client wipe & sync.

Also on the clients page, "make everyone like me" which wipes the server and tells everyone else to wipe. (But I just realized, if we wipe everything from the server.. we lose track of who the remote clients are. Maybe we should keep that...)

Server pane: Wipe server ?

Comment 5

[Ed Lee :Mardak]

In terms of perhaps getting things in for M4, with bug 480457 and bug 480490, we can easily change the Sync Now... button to do a hard refresh and re-add the Wipe Server button to the Advanced pane.

Comment 6

[Dan Mills [:thunder]]

Let's target this for M5.  M4 is too close to being out the door.

As for where this gets placed in the UI, I think we want a new dialog like we discussed the other day:

device [<=> |v] cloud
       |<=    |
       |=>    |
       +------+

[All Data      |v]
|Bookmarks       |
|History         |
|Tabs            |
|...             |
+----------------+

[Sync] [Cancel]

This dialog would open up from the 'Sync Now' button in the Data pane.  Though we should rename that button to something like 'Force Re-Sync'.

A button next to each client in the Clients pane would work, but I think another dialog might be better (maybe?) something that lets you choose the client from a drop-down and then choose which action you want (force wipe, force re-sync...)

And yeah - the server wipe will need to keep the clients collection :-/

Comment 8

[Ed Lee :Mardak]

Leaving this open for now until we get the per-engine UI.

Comment 9

[Ed Lee :Mardak]

Closing 0.3 Tracking Bugs

Comment 10

[Ayan Shah[:ashah]]

Investigating this bug for being potential crossweave automation test case candidate.