1453151 - New bookmark sync validation errors

Status: RESOLVED DUPLICATE of bug 1293163

(Firefox :: Sync, defect)

Description

[Adam Wells]

Attachment: FFNsync

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180410100115

Steps to reproduce:

Enabled the new bookmark sync and about sync addon.


Actual results:

Checked the validation tab in about:sync.  Found a bunch of errors.


Expected results:

No errors

Comment 1

[Thom Chiovoloni [:tcsc] (ex-moco)]

Could you be more specific about which errors you have?

Also, about:sync has a button where it can provide an anonymized export of your bookmarks tree, so that we can inspect how it's corrupted. Can you do this and attach it here?

Comment 2

[Lina Butler [:lina]]

Attachment 8966771 [details] is the anonymized export, but it's not clear to me if the mirror introduced these, or if they were there before. Adam, any chance you ran validation before flipping the pref, too? No worries if not, I should update the blog post and ask folks to validate before and after, for a baseline.

In general, the mirror won't fix problems that are already there. For example, if a record appears in multiple folders, it'll use the most recent one it sees, but won't reupload anything, so the same validation failures are likely to persist. But it shouldn't make things worse.

Comment 3

[Lina Butler [:lina]]

In this case, it looks like deduping doing something funky. All children of `qzIHKIwzNCSk` locally (which is probably "Firefox Nightly Resources", given that some of its children have recognizable Mozilla `fake-favicon-uri` properties, including Mibbit, MDN, and Planet, and an `about:crashes` bookmark) are children of `9J_hly0yEso4` remotely.

On the server, `9J_hly0yEso4` doesn't show up in the menu's `children`, even though its `parentid` is menu, so we move it to `unfiled` because it's an orphan. `9J_hly0yEso4` has a date added of 2018-03-04, so it might have been the old deduping logic kicking in. However, some of those records (`Ia3OqhBjBJh8` and `TMGuh1WOYkqV`), also have `hasDupe: true`, which could indicate the new engine uploaded them.

This looks very much like bug 1293163, so I'm tempted to point the finger at the old deduping logic, but I'll also try to write a full-folder mirror test for this.

Comment 4

[Adam Wells]

(In reply to Kit Cambridge (they/them) [:kitcambridge] from comment #2)
> Attachment 8966771 [details] is the anonymized export, but it's not clear to
> me if the mirror introduced these, or if they were there before. Adam, any
> chance you ran validation before flipping the pref, too? No worries if not,
> I should update the blog post and ask folks to validate before and after,
> for a baseline.
> 
> In general, the mirror won't fix problems that are already there. For
> example, if a record appears in multiple folders, it'll use the most recent
> one it sees, but won't reupload anything, so the same validation failures
> are likely to persist. But it shouldn't make things worse.

No, I did not run validation first.  Let me know if you need anything else.