Bug 2039791 - Filter orphaned and non-folder-parent structure rows from fetch_remote_tree

[mhammond]

moz_bookmarks_synced_structure rows can accumulate with tombstoned/absent or non-folder parent endpoints. The strict dogear by_children call in pass 3 of fetch_remote_tree would fail on these with MissingParentForUnknownChild or InvalidParent respectively.

Workaround: join against moz_bookmarks_synced to both report and skip rows whose endpoints are tombstoned/absent or whose parent is not a folder.

• report via report_error! so we can learn more about what's wrong.
• skip so dogear doesn't see the errors, with the expectation being that either the skip causes no problems (eg, tombstoned items) or are reparented (eg, when parent is missing entirely)

Note this is on top of #7372.

[skhamis]

This looks great! Excited to see if we can nab some of these persistent bookmark issues! Had one comment about exists vs max but don't feel strongly if we don't want to go that route.

[skhamis]

Instead of the exists here we could potentially use MAX that way we don't need the 5 exists. This would reduce the amount of scans this query would be doing.

SELECT
  MAX(child.isDeleted IS 1),
  MAX(child.guid IS NULL),
  MAX(parent.isDeleted IS 1),
  MAX(parent.guid IS NULL),
  MAX(parent.isDeleted IS 0 AND parent.kind <> ?)
FROM moz_bookmarks_synced_structure s
LEFT JOIN moz_bookmarks_synced child  ON child.guid  = s.guid
LEFT JOIN moz_bookmarks_synced parent ON parent.guid = s.parentGuid
WHERE s.guid <> ?

[skhamis]

Actually while thinking about it more we could also just do:

SELECT
  SUM(child.isDeleted IS 1),
  SUM(child.guid IS NULL),
  SUM(parent.isDeleted IS 1),
  SUM(parent.guid IS NULL),
  SUM(parent.isDeleted IS 0 AND parent.kind <> ?)
FROM moz_bookmarks_synced_structure s
LEFT JOIN moz_bookmarks_synced child  ON child.guid  = s.guid
LEFT JOIN moz_bookmarks_synced parent ON parent.guid = s.parentGuid
WHERE s.guid <> ?

Then we can know exactly how many rows are tombstoned? Idk if we really care about that though in regards to what you're trying to actually do.

[mhammond]

yeah, that's a good idea. I took the first one because we don't really need to know counts.

[lougeniaC64]

LGTM!