Ryan Kelly [:rfkelly] Reporter
	Description • 11 years ago

Running Nightly [29.0a1 (2014-01-16)] I managed to get from from FxA account to a clusterURL in our existing phoenix datacentre, which of course doesn't like my FxA-provided credentials.

Sync debug log attached.

It looks like the flow went like this:

  * authed successfully, hit my new experimental tokenserver, was assigned to https://sync1.dev.lcip.org

  * the url given by the new tokenserver was busted, so it got a 404:
    "mesg: GET fail 404 https://sync1.dev.lcip.org/1.1/8/info/collections"

  * this triggered the old-style node lookup code e.g. "Finding cluster for user 8"

  * the existing node-allocation servers happily assigned me a node in phx

  * the phx node failed with a 401 for obvious reasons

  * I got the "password incorrect" screen.

A syncstorage failure like this should trigger it to go back to the tokenserver to check its clusterURL, not to the old-sync node servers.

	Richard Newman [:rnewman]
	Comment 1 • 11 years ago

Ooh, exciting! There are probably going to be more of these.

	James Bonacci [:jbonacci]
	Comment 2 • 11 years ago

We need to triage this on desktop and Android.
So, I added a bunch of people...

	James Bonacci [:jbonacci]
	Comment 3 • 11 years ago

Adding both Meta bugs for now. We can split off if this needs to be addressed cross-platform.

	Richard Newman [:rnewman]
	Comment 4 • 11 years ago

Android shouldn't be affected -- it has a separation between stages. Important to test, though.

	Ryan Kelly [:rfkelly] Reporter
	Comment 5 • 11 years ago

>  * the url given by the new tokenserver was busted, so it got a 404:

Actually no, the tokenserver gave the right URL.  The client stripped off the path component:

"1389916731312	Sync.BrowserIDManager	INFO	initWithLoggedUser has username 8, endpoint is https://sync1.dev.lcip.org/"

I guess the client hard-codes the structure of the path component, and just appends "/1.1/username/" to its clusterURL.  The new servers are expected "/1.5/username/" per new protocol version.

	Nick Alexander :nalexander [he/him] (PTO until Montreallhands August 21, 2023)
	Comment 6 • 11 years ago

Ditto what rnewman said.  If this was busted, we'd have seen it already for each new Account created.

	Edwin Wong [:edwong]
	Comment 7 • 11 years ago

This class of bugs underscores the requirement for using production servers when we go live in nightly.

	Mark Hammond [:markh] [:mhammond]
	Comment 8 • 11 years ago

The patch in bug 959222 will ensure we don't use the old-sync node re-assignment flow.  However, it doesn't yet allow us to support version 1.5 of the token server, which we will track in a different bug

	Mark Hammond [:markh] [:mhammond]
	Comment 9 • 11 years ago

I believe bug 959222 landed support for this.