Add a mechanism to migrate to a new profiles data store
Categories
(Toolkit :: Startup and Profile System, enhancement)
Tracking
()
People
(Reporter: mossop, Unassigned)
References
(Blocks 2 open bugs)
Details
Attachments
(1 external file)
|
Reporter | |
Comment 1•10 months ago
|
||
|
|
Reporter | |
Comment 2•2 months ago
|
||
Beth would you mind giving me some feedback on the Nimbus bits of the attached patch? The goal here is to allow moving a profile from one group database to another. This is to support fixing cases where somehow the profile has ended up in the wrong group (we have users manually modifying prefs etc that causes this and then their profiles no longer show up right in the menus), and users want to be able to import legacy profiles into the new UI which requires moving them to the same group as an existing profile.
Nothing triggers this in the patch yet, its adding an API to do it (ProfilesDataStoreService.switchStore), both Nimbus and the profiles service then take the appropriate steps. But I'm not terribly sure I'm doing the right thing with Nimbus or what invariants I'm probably breaking. What I try to do is unenroll from any active experiments prior to the database being changed and then enroll in the new set experiments after (which may have changed given the change in datastore).
|
||
Comment 3•2 months ago
|
||
I have left a review but I'm concerned about side effects from re-initializing nimbus after all our consumers have registered their update handlers. I think a better way forward would be to force a browser restart after swapping to the new database and re-enrolling in Firefox Labs.
We might want to re-enroll in Labs after the restart (which could require a second restart -- labs can set requireRestart: true in case there are update handlers for features used by Firefox Labs that will do things like set prefs or do disk IO that needs to be consistent. But I do understand that would make it even more complicated.
Description
•