Define and implement repair failure strategy

NEW
Unassigned

Status

()

defect
P3
normal
2 years ago
2 years ago

People

(Reporter: markh, Unassigned)

Tracking

({stale-bug})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Sync Q3 OKR])

Reporter

Description

2 years ago
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.
Reporter

Updated

2 years ago
Duplicate of this bug: 1339633
Assignee: nobody → markh
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [Sync Q3 OKR]
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.
Keywords: stale-bug
Assignee: markh → nobody
Status: ASSIGNED → NEW
Depends on bug 1407067.
Depends on: 1407067
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.