Yeah, we either want to manually invoke OnStoreLoaded() from Connect() if the store is already loaded, or else we want to move the affiliation code out of OnStoreLoaded()
 and into OnInitializationComplete():
 (https://cs.chromium.org/chromium/src/chrome/browser/chromeos/policy/user_cloud_policy_manager_chromeos.cc?q=UserCloudPolicyManagerCh&sq=package:chromium&l=190)

Also feels like we should have a CHECK/DCHECK() if we ever have user policy without an affiliation ID, but not sure where the right place is to check that.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7983fe99488b53b800dbd1434e261590a70c3cbe

commit 7983fe99488b53b800dbd1434e261590a70c3cbe
Author: Pavol Marko <pmarko@chromium.org>
Date: Fri Feb 16 09:39:24 2018

Properly determine user affiliation on synchronous profile load

When a synchronous profile load is happening (e.g. after chrome restart
on Chrome OS), make sure to invoke UserCloudPolicyManagerChromeOS's
OnStoreLoaded handling.
This is also the place where user affilitaion is determined.

BUG= 810013 
TEST=browser_tests --gtest_filter=*UserAffiliation*

Change-Id: Ib4a4b1ad3e61eba637f527dfa89cb5cd1fd2159b
Reviewed-on: https://chromium-review.googlesource.com/908565
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Drew Wilson <atwilson@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537267}
[modify] https://crrev.com/7983fe99488b53b800dbd1434e261590a70c3cbe/chrome/browser/chromeos/policy/user_affiliation_browsertest.cc
[modify] https://crrev.com/7983fe99488b53b800dbd1434e261590a70c3cbe/components/policy/core/common/cloud/cloud_policy_manager.cc

I don't think we need a merge unless someone complains. WDYT?

Update:
This may be contributing to people losing access to ARC++ when the UnaffiliatedArcAllowed policy is set to true.
The fix CL above landed in 66.0.3350.0.

Correction for Comment #6: when the UnaffiliatedArcAllowed policy is set to *false*.

+dskaram
+bhthompson
This is probably causing issues on Chrome OS when
- Site isolaton policies are enabled (causing a chrome restart to apply them)
- UnaffiliatedArcAllowed policy is set to false.
The result is that users lose access to the ARC.

Is merging to M-65 (which will be on stable for a while) still an option?
The CL above is rather small, has not caused any issues on dev since it landed and has broad browsertest coverage.

Thanks!

Adding official merge request.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/835b3e92d3b5a834daa0df2765f6374937cd1b95

commit 835b3e92d3b5a834daa0df2765f6374937cd1b95
Author: Pavol Marko <pmarko@chromium.org>
Date: Wed Mar 14 21:47:24 2018

[Merge to M65] Properly determine user affiliation on synchronous profile load

When a synchronous profile load is happening (e.g. after chrome restart
on Chrome OS), make sure to invoke UserCloudPolicyManagerChromeOS's
OnStoreLoaded handling.
This is also the place where user affilitaion is determined.

BUG= 810013 
TEST=browser_tests --gtest_filter=*UserAffiliation*
TBR=pmarko@chromium.org

(cherry picked from commit 7983fe99488b53b800dbd1434e261590a70c3cbe)

Change-Id: Ib4a4b1ad3e61eba637f527dfa89cb5cd1fd2159b
Reviewed-on: https://chromium-review.googlesource.com/908565
Reviewed-by: Sergey Poromov <poromov@chromium.org>
Reviewed-by: Drew Wilson <atwilson@chromium.org>
Reviewed-by: Maksim Ivanov <emaxx@chromium.org>
Commit-Queue: Pavol Marko <pmarko@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537267}
Reviewed-on: https://chromium-review.googlesource.com/963421
Reviewed-by: Pavol Marko <pmarko@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#705}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/835b3e92d3b5a834daa0df2765f6374937cd1b95/chrome/browser/chromeos/policy/user_affiliation_browsertest.cc
[modify] https://crrev.com/835b3e92d3b5a834daa0df2765f6374937cd1b95/components/policy/core/common/cloud/cloud_policy_manager.cc

The above merge has reached 65.0.3325.167.

Verified on build 65.0.3325.169 that the fix works correctly with the UnaffiliatedArcAllowed policy. (While I haven't performed the verification on 65.0.3325.167, it should work there regardless)

Verified that the issue reproduces on M-64, but does not reproduce on M-65 after the fix landed:
https://docs.google.com/spreadsheets/d/135vF0P5Vqnr6Wye1LNRpKes3QiEnPZG-OU0xT-SMGt0/edit#gid=0