Consider: * User does "Send tab to device". * Device syncs, but finds itself node reassigned. * Local client is reset, and the logs include: > Sync.Engine.Clients DEBUG Resetting clients last sync time > Sync.Engine.Clients TRACE Deleting /Users/skip/Library/Application Support/Firefox/Profiles/g12p4gc3.default/weave/commands.json > Sync.Engine.Clients TRACE Deleting /Users/skip/Library/Application Support/Firefox/Profiles/g12p4gc3.default/weave/commands-syncing.json > Sync.Engine.Clients DEBUG First sync, uploading all items End result is that the pending "send tab" command is lost. This is very tricky to fix as the target client may yet to re-sync (ie, it's likely no client record exists yet). It will also impact repair in the same way. It seems likely that we might need to accept this limitation, but getting it on file for discussion.
Bumping priority for analysis, even if the outcome is accepting the limitation.
I think this is impossible to fix in the general case without running the risk of sending the command twice. If the node reassignment happens after we've sent the command but before the other device Syncs, we really can't know if the other device saw it before the reassignment - and this seems far more likely than happening immediately after this device tries to send the command. Well, maybe not "impossible", but complicated and lots of work that probably exceeds the value gained - and it's likely we will end up using push more and more for stuff that matters, which doesn't have the same set of constraints (although it does have a different set!) So I think this is WONTFIX.