Closed Bug 1586427 Opened 4 months ago Closed 3 months ago

`moz_bookmarks.type` can be null, causing bookmark merges to fail

Categories

(Firefox :: Sync, defect, P3)

defect

Tracking

()

RESOLVED FIXED
Firefox 71
Tracking Status
firefox71 --- fixed

People

(Reporter: Lina, Assigned: Lina)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

One of the errors that show up in telemetry for 71 is:

MergeError: Can't get i64 for column type

There's only one place we do that, and, looking at the Places schema, type doesn't have a NOT NULL constraint! 😳

We have Places maintenance tasks for fixing wrong item types, but not if the type is NULL. I think we could add one, let the sync fail, and have maintenance fix up the DB.

Priority: -- → P3

This commit updates maintenance to change an item's GUID when changing
its type, and adds a task to insert tombstones for the old GUIDs. This
ensures that the item is synced correctly to other clients, without
throwing errors or creating duplicates. We'll still need to handle
existing items on the server; that's bug 1586434.

This commit also adds a new task to fix up NULL types, and moves
the task to remove items referencing nonexistent Place IDs after
the new task. This ensures we do the right thing for items without
a type, and with an fk that doesn't reference moz_places.id.

Assignee: nobody → lina
Status: NEW → ASSIGNED
Pushed by kcambridge@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/ff067ec254cd
Expand Places maintenance tasks for missing and wrong item types. r=mak
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
See Also: → 1609001
You need to log in before you can comment on or make changes to this bug.