PlacesException: Error executing SQL: Integer -1 out of range at index 6

[mhammond]

https://sentry.prod.mozaws.net/operations/fenix/issues/7530815/

In slack @linacambridge diagnosed:

i bet in a-s we're fetching the position or parent or something as a usize or u64 bingo—https://github.com/mozilla/application-services/blob/0ac8bf35683c0bf1b3da9d5cecae293869dfd7b8/components/places/src/storage/bookmarks.rs#L1212 d.position is at index 6, and we're reading it into a u32 in FetchedTreeRow::from_row (position) create_root creates it at position 0... https://github.com/mozilla/application-services/blob/0ac8bf35683c0bf1b3da9d5cecae293869dfd7b8/components/places/src/storage/bookmarks.rs#L70 and sync uses -1 as the default position. but that's only in INSERT, if the item it's inserting didn't exist already! https://github.com/mozilla/application-services/blob/0ac8bf35683c0bf1b3da9d5cecae293869dfd7b8/components/places/src/bookmark_sync/store.rs#L495

but markh remains a bit confused:

so this is a position of -1? I don't see how the root will ever have that position, and the comments in apply_remote_items() suggest a pos of -1 should be temporary? (can our transaction strategy cause this -1 to be seen? ie, could we do our "timed commit" thing in between this upsert and the fixup?)

┆Issue is synchronized with this Jira Task ┆Epic: a-s storage components (backlog)

[rfk]

I'm flagging this for "discuss" because it seems like we're very close to understanding what's going on here and making it actionable.

[mhammond]

Sentry URLs have changed, but this is still happening - eg, https://sentry.prod.mozaws.net/operations/firefox/issues/14274429

[mhammond]

Moved to bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1865184

Change performed by the Move to Bugzilla add-on.