Sync intermittently failing with prod token server

VERIFIED FIXED

Status

Cloud Services
Firefox Sync: UI
P3
normal
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: edwong, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
1.  Using fx-team-<platform>/1390969090/ build:
2. set prefs:
identity.fxaccounts.enabled=true
services.sync.tokenServerURI=https://token.services.mozilla.com//1.0/sync/1.5
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.
(Reporter)

Comment 1

4 years ago
Created attachment 8368068 [details]
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?
(Reporter)

Comment 3

4 years ago
:telliot is this not the correct pref to set?
services.sync.tokenServerURI=https://token.services.mozilla.com//1.0/sync/1.5
Yes, it's the resulting sync node that the client is pointing at (https://sync-1-us-east-1.sync.services.mozilla.com/1.1/8988/info/collections) 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
(Reporter)

Comment 13

4 years ago
This is generally fixed - but intermittent.  I'll update the title.
(Reporter)

Updated

4 years ago
Summary: Sync not working when using prod token server → Sync intermittently failing with prod token server
(Reporter)

Comment 14

4 years ago
syncing generally works however, it looks like:
The token server for production is https://token.services.mozilla.com/1.0/sync/1.5 which means ‘give me a token for sync 1.5’. But the endpoint that it returns is https://sync-1-us-east-1.sync.services.mozilla.com/1.1/$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+]
Blocks: 799726, 905997
Edwin, are you still having problems? That URL looks correct.
Flags: needinfo?(edwong)
(Reporter)

Comment 20

4 years ago
This issue is fixed with 2/3 nightly.
Flags: needinfo?(edwong)
(Reporter)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Priority: -- → P3
good.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.