Re-assigning to vitalii@ since I no longer work on Sync and he's the current bug fixer.

However this looks like the issue may actually be at the signin level; there aren't any cached credentials available at startup. From the logs:
[4784:176:0723/231156.777:VERBOSE1:mutable_profile_oauth2_token_service_delegate.cc(416)] MutablePO2TS::UpdateAuthError. Error: 1 account_id=...

Error 1 means " The credentials supplied to GAIA were either invalid, or the locally cached credentials have expired."

I'm guessing that neither of these is quite right, and the problem is related to either writing the cached credentials or reading them after restarting. 

Mihai, could you please triage it from the Signin perspective? 
As Patrick points out, this does not seem to be related to Sync.

David: Would you be able to take a look at this bug?

This internal bug may be similar:
https://buganizer.corp.google.com/issues/112341866

Is it possible that your domain has set a policy to clear local data on exit? Can you check on the machine where this is occuring by going to chrome://settings/content/cookies, and seeing whether the "Keep local data only until you quit your browser" setting is turned ON?

If that is ON, then you will be signed out each time you restart your browser.

No, we don't have policies on the domain to clear local data on exit. The setting is turned off by default, and is still off. 

We have 2500 machines this is affecting, by the way. This is reproducible on 1709 windows by installing bare copy of Windows and installing the enterprise installer for Chrome.

As an update, it's still happening with 68.0.3440.106, and, curiously, it affects the users on the domain, admin and normal, but NOT the local admin.

I would be happy to get any data needed. 

David, any thoughts on what could be causing this? Could it be some other Enterprise domain policy that causes Chrome to fail to load and decrypt the token from disk on startup?

--Chrome Identity automated triaging--

This bug is Assigned and has gone one month without any activity, so it is being moved to Available to indicate that it is not actively being worked on. If you are working on this bug, please mark yourself as the owner and move back to Assigned. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sorry for the delay, I lost track of this bug.

It is probably not the same as the internal bug mentioned in #4 (which was caused by the google signin page to expire -- the user only has a few minutes to enter their credentials on the signin page, and after this delay the signin would fail).

Is this issue still happening on Chrome M69?

If yes, can you send me a screenshot of chrome:signin-internals ? Ideally the screenshot should be taken after the restart (when the account has just disappeared).

Small disclaimer: this screenshot will contain some personal information such as email addresses. Feel free to anonymize anything there, or you can also send the screenshot to me through email if you don't want it to be accessible publicly.

It is still happening with 69.0.3497.81.

Here's before and after. Addresses included if somebody needs to compare/ contrast on the backend. 

Leaving signin-internals up I see the values updating with fail times.  

Deleted: before restart.jpg 165 KB

	before restart.jpg 165 KB View Download

Deleted: after restart.jpg 112 KB

	after restart.jpg 112 KB View Download

Thanks.

I see an error:
"Load credentials failed with no refresh token for signed in account"

This comes from here:
https://cs.chromium.org/chromium/src/chrome/browser/signin/mutable_profile_oauth2_token_service_delegate.cc?rcl=9fe5f19e441b639346fbe9a35e08b078e8956d2e&l=553

I don't know how what could trigger this in practice.

Assigning to Mihai in case he has ideas.

We get "Load credentials failed with no refresh token for signed in account" in the following case:
* The user signs 
* Chrome gets a refresh token
* To save it to disk, Chrome uses the macOS keychain
* If encryption fails, then we fail to encrypt the token and thus we fail to write it to disk
* On the next start-up, we see "Load credentials failed with no refresh token for signed in account"

In general, restarting the machine (making sure the keychain is unlocked) and re-signing in to Chrome should fix the issue.

I thought this was on windows?

I failed to read the entire bug so I did not notice the fact that this occurs on enterprise computers. We had a similar issue in the past when Chrome failed to store tokens on disk - see https://bugs.chromium.org/p/chromium/issues/detail?id=744626#c29 (copying here for clarity):

TL;DR; In a nutshell you have to set a value ProtectionPolicy to 1 (DWORD type) under HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb

Technical details: 

I nailed down the problem to one particular Windows API function which is used to store sensitive data on disk that is failing for this Windows account and therefore Chrome fails to store any sensitive data to disk (including these credentials, cookies, passwords etc.).

From my research this can be a cause of misconfiguration/bug of your samba store and some threads suggest the solution is to set one registry value to allow windows to store the needed type of data locally.

https://social.technet.microsoft.com/Forums/windows/en-US/47faab6b-d717-4068-bee4-c694811e0066/credential-manager-problems-error-0x80090345?forum=w8itpronetworking

https://support.microsoft.com/en-us/help/3000850/november-2014-update-rollup-for-windows-rt-8-1-windows-8-1-and-windows


vkhabarov@chromium.org: Could you check with the customer whether this or some other configuration forbits Chrome from writing token data to disk? 

I added in that reg value to the key and the problem is resolved on my machine. Feel fairly certain it would work on other machines here too. I will push out a bundle to do this on my test machines and we'll see.
 
We are in fact running on a samba domain, but the bug occurred on a plain, scratch-built, win10 box running the enterprise chrome, that is NOT joined to the domain. 

WHere is chrome trying to write token data to disk? We don't have any policies that would inhibit it, and I'm happy to investigate. I will ask our vendor to investigate as well. 

Curious: when I went to my admin VM, that value was already in place. I started chrome, signed in, and synced. I exited chrome from the menu. Started it again, and got the error. (It didn't say paused, fyi.) Went through the restart-relogin cycle again and it worked. 

I have no idea what set that key. This machine is scratch built, domain joined by hand, and has domain admin tools added. 

Chrome writes the encrypted tokens in a sqlite file in the profile directory.

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time.
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Thursday, 01/17/19 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.