Build: Release 52.0, build 3 Devices: -Asus ZenPad 8.0 (Android 6.0.1) -Xiaomi Mi Pad 2 (Android 5.1) Pre-requisites: - Bookmark some pages on the device before creating FxA - Some history and bookmarks on desktop Steps to reproduce: 1. On the device, go to settings and create a new FxA. 2. On desktop, log in to the newly created FxA. 3. Sync on desktop. 4. Sync on the device. Actual results: - Sync will not be performed. - Synced devices list is empty. - Time of the last sync appears as: "Never".

Could you please attach logcat output as you're going through STRs?

Same issue was raised today on Firefox for iOS. Bug 1344717

I've attached the log file while syncing with the same account used yesterday, when I logged this bug, because today I could not reproduce the problem with other new accounts. Let me know if this helps, or if you need any more info. Thanks!

Thanks, that's helpful. You're failing to sync because of persistent 401 errors while fetching info/collections.

NI myself to follow up on this. I'm still unclear as to why this might happen, which is worrying.

The logs here appear to show attempts to connect to a node that doesn't exist, with a "401inator" in place (which IIUC is an nginx front-end for nodes that don't exist after, eg, they crashed). What should happen here is that the tokenserver token is discarded and another fetched, which should then point at the correct new node to use. The logs don't seem to show any evidence of a new token fetch (but I've no idea if the logs *would* show that). IOW, if the logs *should* show a token fetch, then the problem may be that we don't fetch a new one in some 401 cases.

(In reply to Mark Hammond [:markh] from comment #6) > The logs here appear to show attempts to connect to a node that doesn't > exist, with a "401inator" in place (which IIUC is an nginx front-end for > nodes that don't exist after, eg, they crashed). What should happen here is > that the tokenserver token is discarded and another fetched, which should > then point at the correct new node to use. The logs don't seem to show any > evidence of a new token fetch (but I've no idea if the logs *would* show > that). Android Sync always requests a new token server token, every sync. Each token includes the endpoint to talk to, so this means that at least once (and, if I read the logs provided correctly, actually twice) the token server told Android Sync to talk to a deprecated node. Could that be an issue with the distributed nature of the system? rfkelly/bobm: could that happen? Is it likely to be enough of an issue to work around? The Android Sync client is not likely to get "wedged" into a bad configuration; as soon as the token server provides valid tokens, things should "just start working". > IOW, if the logs *should* show a token fetch, then the problem may be that > we don't fetch a new one in some 401 cases. I just checked, and they don't show token activity by default. There are PII logs (users need to set a flag, and it's only possible in Nightly); there are INFO logs for exceptional situations (which appear by default); and there are DEBUG logs for routine activity (which don't appear by default). So there's a separate ticket to change, so that the logs are always informative, even in the happy path.

> this means that at least once (and, if I read the logs provided correctly, actually twice) > the token server told Android Sync to talk to a deprecated node. > rfkelly/bobm: could that happen? It could happen by human error if nothing else - if we accidentally 401inated a node without first marking it as down in the tokenserver DB.

(In reply to Nick Alexander :nalexander from comment #7) > rfkelly/bobm: could that happen? Is it likely to be enough of an issue to > work around? The Android Sync client is not likely to get "wedged" into a > bad configuration; as soon as the token server provides valid tokens, things > should "just start working". Human error would be the most likely cause for that scenario. I didn't see the actual Sync node in these logs, so I can't double check to make sure something worse happened. I think the worst case scenario would be to migrate users before marking a node down, and to have TokenServer assign them to the migrated node before it is set down. I don't believe that's happened, but it's easy enough for us to check if we think it's warranted here.

(In reply to Bob Micheletto [:bobm] from comment #9) To clear up a point: I can't check an individual user that I don't have the details for, but I can check all migrated servers to see if this is a problem in general.

Too late for firefox 52, mass-wontfix.

It seems that it's safe to chalk up this particular bug to a one-off server misconfiguration. We should be able to notice these problems in the reported telemetry. Syncing again has a good chance of fixing the problem, since we'll get a new endpoint from the token server (eventually, once the misconfiguration is resolved). From the client's POV, the best improvement we could probably make for cases like these is better error state messaging (e.g. "server error, please try again").