Define and implement repair strategy when too many bad records are found

NEW
Unassigned

Status

()

Firefox
Sync
P3
normal
10 months ago
2 months ago

People

(Reporter: markh, Unassigned)

Tracking

({stale-bug})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [Sync Q3 OKR])

(Reporter)

Description

10 months ago
The repair code in bug 1317223 defines the maximum number of "bad" records we attempt to repair (MAX_REQUESTED_IDS in bookmark_repair.js) - any more than that we bail, under the assumption that things are so corrupt that we may end up doing more harm than good, so should probably ask some other device to wipe the server and re-upload everything.

We will probably implement this once we have initial telemetry for bug 1317223 so we can be more confident the maximum number is appropriate (eg, we may choose to radically adjust that maximum as well as implementing the wipe)

This is similar to bug 1340325, although that bug is for when we have a smaller number of bad IDs but no other client is able to supply them.

Updated

10 months ago
Assignee: nobody → markh
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [Sync Q3 OKR]
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.