We've a lot of currently unexplained authentication issues with sync. This bug is a meta bug to try and group them together so we can find any patterns that exist and hopefully get some traction on some of them. I've probably missed a few - please add any that I did.

I had a bad experience this weekend. On my home machine, I started my browser and was connected to Sync, installed an add-on, and then restarted. After restart, I was disconnected from Sync (I was asked to reconnect), and there wasn't a clear error log. However, my password manager didn't seem to have my Sync credentials. I need to look into this more, and I'll post as much detail as I can to an appropriate bug..

I had a bad experience this weekend. On my home machine, I started my browser and was connected to Sync, installed an add-on, and then restarted. After restart, I was disconnected from Sync (I was asked to reconnect), and there wasn't a clear error log. However, my password manager didn't seem to have my Sync credentials. I need to look into this more, and I'll post as much detail as I can to an appropriate bug.

It was the only error log in my Sync logs, which doesn't yield much. That's strange, because I would think that missing my Sync creds would trigger an error log on startup.

(In reply to Chris Karlof [:ckarlof] from comment #4) > It was the only error log in my Sync logs, which doesn't yield much. That's > strange, because I would think that missing my Sync creds would trigger an > error log on startup. The credentials missing isn't treated as an error condition at startup, as it has the same symptoms as the user declining to unlock the master-password - but that case certainly *does* make lots of noise in the logs - which I don't see here (ie, they don't seem to actually be missing in that log), and: > 1418142853983 FirefoxAccounts DEBUG got keyPair > ... > 1418142854177 Sync.BrowserIDManager DEBUG Getting a token > 1418142854384 Sync.BrowserIDManager DEBUG Successfully got a sync token certainly implies they are there. There's also a cluster reassignment, but that looks like it worked: > 1418142858178 Sync.Resource DEBUG mesg: GET fail 401 https://sync-119-us-west-2.sync.services.mozilla.com/1.5/10844704/info/collections > 1418142858178 Sync.Resource DEBUG GET fail 401 https://sync-119-us-west-2.sync.services.mozilla.com/1.5/10844704/info/collections > 1418142858178 Sync.Service WARN 401: login failed. > 1418142858179 Sync.BrowserIDManager DEBUG _findCluster found existingclusterURL, so discarding the current token > 1418142858179 Sync.BrowserIDManager INFO Fetching assertion and token from: https://token.services.mozilla.com/1.0/sync/1.5 > ... > 1418142858242 Sync.BrowserIDManager DEBUG _findCluster returning https://sync-165-us-west-2.sync.services.mozilla.com/1.5/13772492/ > 1418142858242 Sync.Service DEBUG Cluster value https://sync-165-us-west-2.sync.services.mozilla.com/1.5/13772492/ > ... > 1418142858408 Sync.Resource DEBUG mesg: GET success 200 https://sync-165-us-west-2.sync.services.mozilla.com/1.5/13772492/info/collections But it caused a sync reset - I'm not sure if that's expected or not: > 1418142858498 Sync.Service INFO Sync IDs differ. Local is n6-ySEo1jFl4, remote is nFxMKWHykV8t > 1418142858498 Sync.Service INFO Service reset. And that seemed to cause the scary: > 1418142859262 Sync.Engine.Bookmarks WARN DATA LOSS: Both local and remote changes to record: VNikLZj-EZOZ1 and it *looks* like a full sync started due to the reset, but that was interrupted by the app quiting causing the error log. So I'm not sure what to make of that, but there doesn't seem to be anything specifically auth related there.

Here's what I get when I log TRACE to console. Itw seems like something in here should trigger an error log in my about:sync-log. 1421292248460 Sync.Service INFO Loading Weave 1.36.0 1421292248462 Sync.Engine.Clients DEBUG Engine initialized 1421292248463 Sync.Engine.Clients DEBUG Resetting clients last sync time 1421292248469 Sync.Engine.Bookmarks DEBUG Engine initialized 1421292248472 Sync.Engine.Forms DEBUG Engine initialized 1421292248476 Sync.Engine.History DEBUG Engine initialized 1421292248480 Sync.Engine.Passwords DEBUG Engine initialized 1421292248483 Sync.Engine.Prefs DEBUG Engine initialized 1421292248486 Sync.Engine.Tabs DEBUG Engine initialized 1421292248487 Sync.Engine.Tabs DEBUG Resetting tabs last sync time 1421292248493 Sync.Engine.Addons DEBUG Engine initialized 1421292248494 Sync.Service INFO Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:34.0) Gecko/20100101 Firefox/34.0 1421292248498 Sync.SyncScheduler DEBUG Clearing sync triggers and the global score. 1421292248499 Sync.Status DEBUG Status.login: error.login.reason.account => error.login.reason.account 1421292248499 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed 1421292248499 Sync.Service DEBUG Caching URLs under storage user base: https://sync-165-us-west-2.sync.services.mozilla.com/1.5/13772492/ 1421292248499 Sync.Status DEBUG Status.login: error.login.reason.account => error.login.reason.account 1421292248500 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed 1421292248500 Sync.AddonsReconciler INFO Registering as Add-on Manager listener. 1421292248500 Sync.AddonsReconciler DEBUG Adding change listener. 1421292248501 Sync.Tracker.History INFO Adding Places observer. 1421292248510 Sync.Status DEBUG Status.login: error.login.reason.account => error.login.reason.account 1421292248510 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed 1421292248511 Sync.Status DEBUG Status.login: error.login.reason.account => error.login.reason.account 1421292248511 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed 1421292248512 Sync.Status DEBUG Status.login: error.login.reason.account => error.login.reason.account 1421292248512 Sync.Status DEBUG Status.service: error.login.failed => error.login.failed

After talking with Mark we came to the conclusion that the login error was transient and shouldn't warrant a sync-log entry.

(In reply to Zachary Carter [:zaach] from comment #7) > After talking with Mark we came to the conclusion that the login error was > transient and shouldn't warrant a sync-log entry. To be clear, also that this behaviour (ie, code path) changes in bug 1205111.

(In reply to Zachary Carter [:zaach] from comment #7) > After talking with Mark we came to the conclusion that the login error was > transient and shouldn't warrant a sync-log entry. This is a kind of franken-bug that has morphed into a meta bug, so I'm reopening to help track other auth issues in dependent bugs.

Clearing the priority from all our meta bugs.