In bug 1317223 we are implementing a repair process for bookmarks. The initial implementation that lands doesn't have a strategy for dealing with a "successful" repair process that fails to actually perform a repair (ie, when the repair process works as intended, but none of the other devices are able to provide the information needed) Currently it is dumb - once a repair completes we do nothing. The next time a validation runs, it will restart a repair. There is a reasonable chance that this next repair will simply attempt the find the exact same items the previous repair failed to provide, ad-nauseam. Given the intent here is to unblock bidirectional sync for iOS, we probably need to be smarter here. For example, at some point we should probably give up and ask another device to wipe the server and perform a full sync. However, it's not clear if we should do this after the very first attempt - it *is* possible a second attempt will succeed (eg, because a rarely used device happens to be available during that second attempt) - but at some point we need to fallback so iOS is unblocked. We'll probably land the repair code such that it doesn't ride the trains to release and use telemetry to guide our decisions - but we almost certainly need an answer here before it can ride the trains.

This is an assigned P1 bug without activity in two weeks. If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword. Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.

Depends on bug 1407067.