-
Notifications
You must be signed in to change notification settings - Fork 1
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
Verify that user data is not completely re-synced post migration. #45
Comments
New sync id is |
Your client fails to find the |
Can we confirm from server-side migration logs whether the record |
My first theory here is that perhaps the migration script is calculating the |
The client got a
|
Erik migrated the user to After the 401 error log, the client appears to have sync'd to the new durable sync node without a full reupload! Log EDIT: It did reupload its Tabs (it originally had 1 tab, and reuploaded). |
Though I notice one oddity, the Tabs collection in about:sync fails to load, reporting an Error:
Restarting the browser lead to a sync error w/ the same HMACmismatch: Log |
Tabs are currently set to be solely stored in memcached on the server |
Hrm, the hmac mismatch is very strange indeed. If you use the |
I also wonder if we're seeing the HMAC error on the tabs collection because that's the only one for which we're trying to download any records - all other collections are (correctly) treated as not having any remote changes. Trying to add a second client to this cluster might result in in additional HMAC errors being surfaced. |
Actually, from the logs, I wonder if there is somehow a second item in the "tabs" collection. The logs around the HMAC error say this:
So it skips the incoming tab item for itself, which is good.
But here we see that it tried to apply a record, and failed to do so due to the HMAC error. Does that mean that there's second BSO in the To check my understanding: we expect that the migration script will not populate any items into the "tabs" collection, because that collection does not exist in MySQL on the storage nodes. Is that accurate? |
about:sync isn't helpful here, it reports the HMACMismatch error and is stuck in the "Fetching records..." state for tabs, even after dismissing the error message. |
Ugh, OK. Any chance you'd be willing to hit the server API directly and pull down the record(s) for inspection? :-) |
Someone would need to help me figure out how to get the appropriate Authorization header needed to query the backend. However I was luckily able to grab this count from about:sync's logging of the Is it possible we have stale tabs data from mysql? I'm not familiar w/ the I'm also wondering the ramifications of migrated user data including entries for tabs in the metaglobal and I think |
Nevermind, think I've got the hang of this.. |
I don't think it will ever be written back to mysql. Can we look in the source tables on the old node to see if there were any there? |
@rfk thanks for the hints Need to confirm some of these details w/ ops but it seems this was due to stale tabs data in spanner. For this migration test, the client was a new account:
If a client "Signs Out" of FxA/Sync while on the Python node, clients and forms collections perform a kind of "reset" on the client side and the accompanying records for the device are We had a couple problems here:
So stale tabs data was left around + I think combined w/ the "reset" -- this "reset" must change some state of the tabs collection used for HMAC validation. Does that make sense? Another note: though we won't migrate tabs data, we'll migrate an entry for it in |
Aha, yes I think this would explain it! At step (1) the client would have created new bulk storage keys in At step (2) the client would have seen that it had been re-assigned to a new, empty storage node, and would have re-initialized the sync data including At step (3) you copy the new Except for the "tabs" collection, where it finds the old data that we encrypted using the old storage keys I'm not sure what effect the explicit signing out would have had - perhaps if you get a node re-assignment while you're signed in, Firefox is able to re-use the previous keys from Regardless, I think this is a plausible explanation, Thanks for taking the time to dig in to the details here! |
Re-opening this one as it looks like we may have hit the issue again from yesterdays client testing |
Logs for my last round of successful attempts (on stage): pjenvey-stage-migrate1: Did a forceful "Sign out" out of Sync to force lookup back to the Spanner node after its migration All 3 of these test accounts migrated successfully. |
Plan here is as follows:
128881199 - tublitzed@yahoo.com
). Current pointed to this legacy sync node.about:sync
. Enable success logging by settingservices.sync.log.appender.file.logOnSuccess
to true inabout:config
.~The text was updated successfully, but these errors were encountered: