Open Bug 1297955 Opened 4 years ago Updated 3 years ago

Work out how to repair server state when incoming record references a non-existing parent


(Firefox :: Sync, defect, P3)





(Reporter: markh, Unassigned)


(Whiteboard: [data-integrity])

Broken out from bug 1276823. Consider an incoming record we've never seen before with a reference to a parent GUID we've never seen before, and which doesn't appear in this Sync.

Desktop will apply the incoming parent, mark it as an orphan and re-parent to the unfiled folder. At this point the local and server states are inconsistent - the record remains on the server with the invalid parentid, but it exists locally with a different existing parentid.

Either of 2 things could happen in the future:
* The bookmark arrives - we will then get closer to a consistent state (bug see the test |test_dupe_reparented_to_future_arriving_parent_bookmark| in test_bookmark_duping.js (part of bug 1276823) - there are strange de-duping scenarios where we remain inconsistent.

* The bookmark never arrives. We will forever remain in an inconsistent state.

At some point, desktop should conclude the missing parent will never arrive and update the server record to reflect the local reality.

It's difficult to guess what priority this should have (ie, how many people are likely affected). Reporting validation results via telemetry might give insights.
Priority: -- → P3
Priority: P3 → P2
Priority: P2 → P3
You need to log in before you can comment on or make changes to this bug.