-
Notifications
You must be signed in to change notification settings - Fork 272
Bug 2056116 - Don't crash sync on logins with invalid guids #7491
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
jo
wants to merge
1
commit into
mozilla:main
Choose a base branch
from
jo:validate-ids
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry you are hitting this. I'm not sure of the entire context here, but this assertion was really more a sanity check for our code - ie, the server will accept anything as a GUID. This means that if this record somehow ended up coming from the old passwords engine, then the record may well already be on the server.
It's not clear to me how much of your strategy here relies on "Such a record can never have reached the server". Another strategy (which I'm not sure I like entirely, but which I think would work) would be to just remove the assertion. That would leave us without this safely check, but I don't recall anyone ever hitting it in the past and if it turns out this ID was being used in the past then maybe that's not such a crazy idea.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(oops, but I also meant to say this patch looks fine to me if this is the route we should take)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, cool, it’s definitely possible that this ID is already on our servers. In that case, I’ll take the check out of here but still fix the
add_with_meta. And do you think I can migrate the IDs that are already in the store (the ones that were just migrated viaadd_with_metaon the desktop) here?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the GUID hit the server, then wouldn't a mobile logins engine download it and re-upload a record with the same GUID and hit the same panic? I'm not against either solution (removing the assertion or skipping the record), but I'd like to understand what's happening better before we commit to either one of them.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point - maybe it was Desktop sync only, no mobile involved?
I think this happened:
add_with_metawithout validating guidBefore Rust logins, this login could have been synced with the old logins sync engine, but maybe only to other Desktop's?
That's why I thought we need to fix this on three levels:
add_with_metato add invalid ids (or fix them, guarded by a flag)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this only makes sense if it came from desktop originally - this error should mean it was impossible for it to originate on mobile. Even then it seems odd though - "
add_with_metawithout validating guid" doesn't fully explain it because someone generated a guid (ie, it's never a free-form text field), and the desktop password engine has always generated "valid" GUIDs up to now.Fixing it is also complicated in theory. It would mean you need to leave a tombstone behind so it doesn't get duplicated on other devices. And it still leaves the (improbable!) possibility it gets edited on another device without the migration implemented yet, so the tombstone is resurrected.
This all seems so edge-casey - if we can't identify how this ID might have been created legitimately, then the best thing probably is to just skip the record entirely, both reading and writing - it seems unlikely that's actual data loss. That strategy couldn't work for bookmarks though - you can't sanely just skip a single parent folder. So it seems unfortunate that the problem looks like it needs to be solved in every engine which sucks as ever engine is theoretically susceptible.
If it helps or hurts, you can almost certainly reproduce this with about:sync - it lets you edit/add records via plain JSON - that's how I verified the server doesn't reject crazy guids. Indeed, if it seems like there's exactly 1 user with this problem, someone doing silly things with about:sync is the most likely explanation I can think of.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, that leaves me pretty stumped, too.
Just a thought: It could be a very old login, from a time when it might have been possible to create strange ids, eg via import or whatever. There were also times when extensions could write logins directly.
How exactly would you handle this now? Should we monitor the error for now to see if it occurs more often?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If literally one device, then yeah, I'd say ignore it. I don't really know how to read those stats in terms of client vs crash counts - but raw crash counts are very low, and I think the check makes sense rather than loosening here? So somehow making noise and ignoring this rather than crashing or otherwise blocking other items seems ideal? Sorry I haven't dug into the actual impl here to know if that actually makes sense
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it? This is a genuine question? 😅 I'd be easily convinced we just drop the assert - love opinions from everyone :)