1866526 - De-dupe history records on the server

Status: NEW

(Application Services :: Places, enhancement, P3)

Description

[Mark Hammond [:markh] [:mhammond]]

From github: https://github.com/mozilla/application-services/issues/5487.

In the history schema evolution PR, Lina taught me that sometimes we can have records on the server with the same URL, but different GUIDs.

This leads to weird corner cases: if the two records have different titles/unknown fields which one is the right one? What happens if the relative order of the two records changes between syncs? I think we should do something to try to fix this.

The first part is how this happens in the first place. @linabutler can you expand on the steps to cause this? Is there some way to prevent it from happening?

The second part is recovery. If we see 2 incoming dupe records (i.e. records with the same URL, but different GUIDs), I think we should do a reconciliation that removes the dupe:

• Figure out a deterministic way to pick the "real" record (maybe the lowest GUID). This is the record that we will continue to use going forward.
• That record's visit list is computed by merging the visits from all records together
• For other fields like title and unknown_fields we have a couple options:
  • Use the value from the real record.
  • Use the value from the record with the latest visit
• We upload the real record, for the other records we can either:
  • Upload a tombstone. This seems nice, but we need to figure out how this would affect other clients. We don't want this to delete their history.
  • Leave the record alone and don't upload anything for it.
• If other clients add visits to one of the non-real records, then we should add those visits to the real record but not change it's GUID.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.