-
Notifications
You must be signed in to change notification settings - Fork 276
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.
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 :)
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.
The
is_valid_for_sync_servercheck behaves differently from the server-side Python implementation referenced in the comment above the function as well as in the Rust successor's validation regexp: the client-side validation also checks for a comma in the ID. This difference in validation actually argues in favor of removing the client-side validation entirely.At the very least, as a minimal fix, we definitely shouldn’t panic about this. What do you think - the release is in a week, and I think we might want to include a fix for 2056116?
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.
So I've broken this down into two parts:
add_with_meta(and optionally fix them via a feature) Bug 2056116 - Validate guids in add_many_with_meta #7524