Closed
Bug 1297955
Opened 9 years ago
Closed 4 years ago
Work out how to repair server state when incoming record references a non-existing parent
Categories
(Firefox :: Sync, defect, P3)
Firefox
Sync
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: markh, Unassigned)
Details
(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.
Updated•9 years ago
|
Priority: -- → P3
Updated•9 years ago
|
Priority: P3 → P2
Updated•8 years ago
|
Priority: P2 → P3
Reporter | ||
Comment 1•4 years ago
|
||
dogear handles this now.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•