Closed Bug 965910 Opened 6 years ago Closed 6 years ago

Sync intermittently failing with prod token server


(Firefox :: Sync, defect, P3)






(Reporter: edwong, Unassigned)


(Blocks 1 open bug)


(Whiteboard: [qa+])


(1 file)

1.  Using fx-team-<platform>/1390969090/ build:
2. set prefs:
3. sign in with an acct, add bookmark, and select sync now
4. open a new profile with same build, prefs, and sign in with same acct
5. select - sync now

actual: bookmark is not synced
I've also tried restarting both profiles.  Sync now from either profile.  Karl also confirmed this.
Attached file sync-log.txt
Gonna ask the obvious question here - looks like it's pointing at a sync1.1 instance? Is this just a URL oversight, or are we accessing the wrong URL?
:telliot is this not the correct pref to set?
Yes, it's the resulting sync node that the client is pointing at ( that I'm concerned about.
This is related to how (on desktop) we construct the storage endpoint from the token server response. Nightly currently does it the way legacy sync does it by "building" it like: 

> this.service.clusterURL + SYNC_API_VERSION + "/" + this.identity.username + "/"

where SYNC_API_VERSION = "1.1" and this.service.clusterURL is the token server response with the path stripped down to "/". This happens to work because it matches the current token server response, modulo 1.1/1.5 versions in the path. 

Bug 960887 fixes this process to use the token server response in FxA Sync and do it old school for Legacy Sync. This Bug was backed out last night due to test failure garbage.

But :rfk says using 1.1 in the new storage URLs will work just fine for now.
FWIW, the test failures were related to something else, which we've tracked down this morning, so hopefully this detail will get cleared up in tomorrow nightly, but I don't think this is related to edwin's issue.
OK, good to know. That's the main thing that stood out from the logs for me.
Hmm, that log doesn't seem to show much bookmark-related activity, but this is a little suspicious:

   1391108334090	Sync.Engine.History	DEBUG	Records that will be uploaded again because the server couldn't store them: hmDoOdoTZDmE, XumM6hGPdQE6, 2BFYI3rleCOZ, Wzd_fdDeCl

I'll try to reproduce.
This worked OK for me on Windows, bookmark synced successfully from one profile to another and back again.  Edwin is this the only sync log from your system?
Ah, so I was using Nightly, I'll try with a fxa-team build
Unable to reproduce with that specific build either (again on Windows).  Platform specific bug maybe?
I see some not-properly-syncing behaviour if I try throwing some folders into the mix, will work through that in more detail
This is generally fixed - but intermittent.  I'll update the title.
Summary: Sync not working when using prod token server → Sync intermittently failing with prod token server
syncing generally works however, it looks like:
The token server for production is which means ‘give me a token for sync 1.5’. But the endpoint that it returns is$UID. Note the 1.5 vs 1.1.

the client is building that URL - thus we're waiting for a patch to land to resolve.
This should be resolved now, meaning we landed the prod token server url in Desktop, and Desktop should be using 1.5 storage URLs.
It landed early this morning in Bug 960887. Desktop team is spinning up new Nightly builds, so I'm hoping you can see that in a couple hours at the latest.
We need to have someone look into this...
Whiteboard: [qa+]
Edwin, are you still having problems? That URL looks correct.
Flags: needinfo?(edwong)
This issue is fixed with 2/3 nightly.
Flags: needinfo?(edwong)
Closed: 6 years ago
Resolution: --- → FIXED
Priority: -- → P3
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.