Patrick, could you take a look at this? Would be good to confirm repro-ability and whether it appears like a Sync issue or a Signin one.

Bumping priority.

I wasn't able to repro on Windows or Linux M63 after several attempts. For clarity, how are you deleting the profile? Deleting the folder from the computer, or using "Remove this person" or both? 

I will attempt on M62 Mac when I reunite with my Macbook later today. 

I cannot repro either. However, based on the 2 screenshots, here is what I think happened (I get the same screenshots as you if I do a sign-in followed by a manual sign-out):
* You second sign-in was successful and sync happened once. That's why you got the theme.
* Something afterwards triggered a force logout. That's why you are actually signed out. One possibility is that the Sync server sent forced sync disabled which leads to a sign-out event (we've had a case like this in the past where that account was always forced signed out by sync).

Roger: If you can repro this, could you please open chrome://histograms, search for Histogram: Signin.SignoutProfile and send me the contents of that histogram. That would allow us to understand what is the source for the sign-out event (the list of fields is in https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_metrics.h?rcl=7e7162befb95f9f279a7b1efb6bba37a51d9e448&l=29 )

To delete the profile, I used "remove this person" from within chrome ui.  I did not restart chrome in between.

Mihai: I will try to repro and capture histograms.  In the mean time, I still have the profile, so if you need me to poke around and get more data let me know.

I wasn't able to repro on Mac M64. I second Mihai's theory that there was a forced signout.

For now I could look at the server data for the account to get a bit more clarity on what happened. I'd need your permission to do this though.

Could you try opening chrome://histograms - just in case that histogram is still available on the client.

The profile was still open and I found the following histogram:

Histogram: Signin.SignoutProfile recorded 2 samples, mean = 3.0 (flags = 0x41)
0  ... 
2  ------------------------------------------------------------------------O (1 = 50.0%) {0.0%}
3  O                                                                         (0 = 0.0%) {50.0%}
4  ------------------------------------------------------------------------O (1 = 50.0%) {50.0%}
5  ... 

2 == SIGNIN_PREF_CHANGED_DURING_SIGNIN
4 == ABORT_SIGNIN

I think that the histograms are collected for all profiles - so chrome://histograms is *not* per-profile, but aggregates data for all profiles

1. SIGNIN_PREF_CHANGED_DURING_SIGNIN is only logged when the profile was initialized - see https://cs.chromium.org/chromium/src/components/signin/core/browser/signin_manager.cc?rcl=edeeccc22bfe46cabdc071eae048d9c0f6849c5b&l=270 .

2. ABORT_SIGNIN is logged in the following case:
a) when a sign-in flow is given up - see https://cs.chromium.org/chromium/src/chrome/browser/ui/sync/one_click_signin_sync_starter.cc?rcl=edeeccc22bfe46cabdc071eae048d9c0f6849c5b&l=409 or 
b) when the sync settings are closed and there is an auth error - see 
https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/settings/people_handler.cc?rcl=edeeccc22bfe46cabdc071eae048d9c0f6849c5b&l=607
c) When the user selects Undo on the sync confirmation dialog - see https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/signin/sync_confirmation_handler.cc?rcl=edeeccc22bfe46cabdc071eae048d9c0f6849c5b&l=83

I think the only possibilities are 1) and 2.b).

The case 1) is really unexpected - are you using an account that has a sign-in policy attached to it?

The case 2.b) is a possibility - maybe you hit an transitive auth error while the sync settings screen was visible. But that does not explain why at list part of your data was synced down.

Roger: Could you please explain how you did steps "4/ delete the profile" and "5/ create another new profile" (did you choose to create a new profile on the managed account dialog? or did you click undo on the Sync confirmation dialog, then created a new profile and then signed in)?

See screenshot, I used rogertatest5@gmail.com as account.  This is a consumer gmail account and I don't believe you can set policies for these accounts.

See comment #6 for how I deleted the initial profile. I did nothing special when I created that profile.  I signed in and clicked "OK got it".  I did not click undo or anything like that.  The new profile was created from the "manage people:" dialog.

If this is a consumer account, then I cannot explain the SIGNIN_PREF_CHANGED_DURING_SIGNIN. Maybe this got recorded before and for a different profile.

I think the only potential explanation is 2.b, but that would mean that sync started synching your data, then got an auth error while sync still consider that the first initialisation did not happen.

Patrick: Would you have any idea if case 2.b can occur?

wrt SIGNIN_PREF_CHANGED_DURING_SIGNIN, if you say that histograms are not profile specific, then this could be other profiles.  I have two other profiles in this chrome install that are signed in to dasher accounts.

2.b can definitely occur; I was able to create a 2.b scenario by killing the renderer process for the sync settings page. I am still a little surprised that some of your sync data came through though. 

I think I would be able to provide a bit more clarity if I could look at the server-side data/events for this account. 

I am the owner of rogertatest5@gmail.com and I give you permission to look at the server side data/events for this account.

Thanks. Unfortunately there's no smoking gun in the server data. Following the second signin the macbook successfully downloaded updates, encrypted all its data, then re-committed the encrypted data as expected. Then it stopped doing anything. It doesn't look like the sync server forced the signout; this would be evident in an error code which in this case wasn't set. 

So the sequence of events as I understand it is:

1) Sign in completed
2) Sync settings dialog opened; at this point sync hasn't yet started
3) Sync passphrase created
4) Sync starts, proceeding to download and encrypt data
5) Some mystery entity aborts sign in, logging you out and stopping sync

What this mystery entity is or why it aborted sign in is (obviously) a still a mystery, but it doesn't seem to be reliably reproducible. 

Sequence is correct from my point of view as the user.  I also created a new profile and signed in with this test account on my corp ubuntu box, and all seems good there, including having to type the new passphrase I set for the sync data.

So it seems to me that everything worked as expected server side.  But client side, some mysterious event caused a sign out.

I'm not sure if this is actionable at this point. A forced signout from the server can result in the reported state, and as far as I know we plan to continue to support forced signout. If it starts happening regularly or reliably that's a different story, but for now I'm going to close this.