Handle Sync storage deprecation indicators for Firefox Accounts migration

VERIFIED FIXED in Firefox 37

Status

()

defect
P1
normal
VERIFIED FIXED
6 years ago
2 years ago

People

(Reporter: rnewman, Assigned: nalexander)

Tracking

(Blocks 1 bug)

unspecified
Firefox 37
All
Android
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(fennec+)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment)

Blocks: 956445
Blocks: 905997
Whiteboard: [qa?]
Duplicate of this bug: 908466
Blocks: 799726
Blocks: 895518
Summary: Handle and upload migration sentinels for Firefox Account transitions → Handle and upload migration and storage deprecation sentinels for Firefox Account transitions
tracking-fennec: --- → 29+
Priority: -- → P1
Whiteboard: [qa?] → [qa+]
If we aren't deprecating in Fx29, let's be more realistic.
tracking-fennec: 29+ → 31+
No longer blocks: 956445
Blocks: 999916
Blocks: 1008066
tracking-fennec: 31+ → +
rnewman: there's code for this that I've confused with Bug 895526.  Is this handling Firefox Account migration sentinels?  Can we improve the bug title?  Is Bug 1091189 a dupe of this?
Flags: needinfo?(rnewman)
Summary: Handle and upload migration and storage deprecation sentinels for Firefox Account transitions → Handle Sync storage deprecation indicators in
I just dug up this bug to say "yes, Bug 1091189 is a dupe" :)

This is to handle the sentinel left in a 1.1 storage account saying "you're now this FxA, go hence".

There's code in the pull req that might be useful.
Flags: needinfo?(rnewman)
Summary: Handle Sync storage deprecation indicators in → Handle Sync storage deprecation indicators for Firefox Accounts migration
Assignee: rnewman → nobody
Status: ASSIGNED → NEW
Blocks: 1098012
rnewman: oh, so racy.  It appears to be fine to delete an Android Account during a Sync operation, terrifying though that is.  However, I am a cautious person, so I also added a flag to the Old Sync account that tries to delete the Account again (during a future sync) if we should fail, or hit a timing issue with the pickle file, etc.  This is not a bullet-proof solution: if we were to find a device that could *never* delete the Account during Sync, we'd stop syncing ('cuz I early abort syncs) but never remove the Account.  Eventually, we'll deprecate the Account type entirely and such accounts will be pruned.

We could arrange for the FxAccountSyncAdapter to scan the set of Old Sync accounts and remove those scheduled for reaping as well; this would address the above problem.  (Assuming that you can remove a *different* Account during a Sync.)

Arranging to persistently retry deleting the Account *outside* of Sync flow is do-able but irritating: a possibly sticky Intent with a backing IntentService... it's heavy for what it gives us.

Weigh in.
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Attachment #8538216 - Flags: review?(rnewman)
Attachment #8538216 - Flags: review?(rnewman) → review+
Duplicate of this bug: 1091189
https://hg.mozilla.org/mozilla-central/rev/deee031b754a
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
Depends on: 1119051
For QA, here are STR for testing a migration flow with Android as a second device:

1) start Desktop Nightly with a fresh profile;
2) follow instructions at https://id.etherpad.mozilla.org/sync-migration-testing to configure Desktop for Old Sync;
3) start Android Nightly (fresh);
4) Android Settings > Accounts > Add Account of type "Firefox Sync (deprecated)"
5) pair your Android and Desktop Nightly builds, following XXX;
6) force a sync to make sure everything is happy;
7) change the Desktop Nightly clusterURL, again following https://id.etherpad.mozilla.org/sync-migration-testing;
8) restart Desktop Nightly;
9) observe yellow bar offering upgrade process;
10) select upgrade and complete sign in flow on Desktop Nightly;
11) before confirming account, force a sync on Android and verify Sync completes (no migration sentinel yet);

WARNING: Bug 1119051 [1] makes the legacy Sync hang (spin indefinitely)
when checking for a migration sentinel that is *not* present.  When a
sentinel is present, everything should work, so you can continue this
flow, but be aware.

12) confirm new Firefox Account via email and complete migration flow in Desktop Nightly;
13) force a sync on Android Nightly;
14) observe migration using |adb logcat|, or see "Finish upgrading
Sync?" notification.
15) tap notification, observe email is pre-filled and not editable;
enter password, observe sync begin.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1119051
Flags: needinfo?(mhammond)
Flags: needinfo?(kthiessen)
Thanks Nick, I just pasted them into https://id.etherpad.mozilla.org/sync-migration-testing as I know I'll never refind this bug later :)
Flags: needinfo?(mhammond)
Thank you for these, Nick.  Have you ever considered offering a master class in writing STR?  I know some folks, both internal/paid staff and volunteer, who could benefit.
Flags: needinfo?(kthiessen)
QA Contact: kthiessen
I have successfully migrated my main Legacy Sync account with these steps without incident.  Marking VERIFIED.
Status: RESOLVED → VERIFIED
Product: Android Background Services → Firefox for Android
You need to log in before you can comment on or make changes to this bug.