Closed Bug 972590 Opened 10 years ago Closed 10 years ago

Unable to sync after aurora uplift

Categories

(Firefox :: Sync, defect, P1)

x86_64
Windows 8
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: ally, Assigned: Gavin)

References

Details

(Whiteboard: [qa+])

Attachments

(1 file)

Attached file sync error log
I have an old sync account. After the Aurora uplift, I have gotten a steady stream of "unknown error"s. :rnewman tells me that old sync should continue to function.  I think this is probably the most relevant part of the log:

1391720723004	Sync.Service	INFO	Not ready to authenticate in verifyLogin.
1391720723004	Sync.Status	DEBUG	Status.login: success.login => error.login.reason.initializing
1391720723004	Sync.Status	DEBUG	Status.service: success.status_ok => error.login.failed
any ideas here folks?
Flags: needinfo?(mhammond)
I tried to reproduce this with a "clean" setup.  

- Installed an Aurora28 build from 20140129
- Setup a Legacy Sync account and Sync Now a few times (single device)
- Checked for updates and got the expected build for Aurora29 build for 20140224
- Sync Now again with success.

Ally are you still seeing this on the build/profile you reported against?
Is so, I would wonder if something is up with https://phx-sync467.services.mozilla.com/
This is very strange - the entry:

1391720723004	Sync.Service	INFO	Not ready to authenticate in verifyLogin.

should be impossible using legacy sync - it implies browserid_identity is being used - but nothing else in the logs has that implication - eg:

1391720723003	Sync.Service	INFO	Logging in user shoxopduknvqasrlluv2xtfeid7jbicc
1391720723003	Sync.Service	DEBUG	Caching URLs under storage user base: https://phx-sync467.services.mozilla.com/

both imply the legacy sync identity as expected.  The legacy provider has:

  get readyToAuthenticate() {
    // We initialize in a fully sync manner, so we are always finished.
    return true;
  },

which is why I say it should be impossible.  Could you tell me what the pref 'services.sync.fxaccounts.enabled' is set to?
Flags: needinfo?(ally)
Flags: needinfo?(mhammond)
"Nothing's impossible with Sync" and that is why (former) sync engineers drink.

services.sync.fxaccounts.enabled = true

Still can't sync, though nightly is a different build test days but aurora & beta are 'bout the same.

It might be worth noting that this is a profile that bounce between desktopfx & metrofx, as well nightly, aurora & beta.
Flags: needinfo?(ally)
Wild speculation: at some point the "when I hit this case, switch over to the FxA identity manager" code ran in error.

Also, I'd be surprised if the upgrade/downgrade case was well tested, and if Metro switching were tested at all.
(In reply to :Ally Naaktgeboren from comment #4)
> "Nothing's impossible with Sync" and that is why (former) sync engineers
> drink.

And a new breed of alcoholics are forming :)
> 
> services.sync.fxaccounts.enabled = true

Well, that should be "impossible" too given the logs, but there you have it.  I suspect flipping this to false will fix your problem - but not answer how we got into that state.

(In reply to Richard Newman [:rnewman] from comment #5)
> Wild speculation: at some point the "when I hit this case, switch over to
> the FxA identity manager" code ran in error.

Yeah - although theoretically that means .startOver() was called, which seems strange.  Also strange is (a) why the rest of the logs imply a legacy provider and (b) that no "Sync.BrowserIDManager" log entries appear.  Oh, and (c), why I'm now out of hard liquor.

> Also, I'd be surprised if the upgrade/downgrade case was well tested, and if
> Metro switching were tested at all.

Yep :(
Priority: -- → P1
Whiteboard: [qa+]
Assignee: nobody → gavin.sharp
Ally, are you still seeing these problems?
Flags: needinfo?(ally)
Flipping the pref lost the credentials on one profile, the other worked and is successfully syncing.
Flags: needinfo?(ally)
I'm just trying to figure out what's actionable here. Comment 0 (and this bug's summary) describes "upgrading to 29 broke my old sync".

It sounds like now you've gone and switched over to new sync, so we're unlikely to figure out what went wrong in the first place?
Going to call this WFM in the absence of any actionable info.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: