Another thing that it might be interesting to consider is whether we want to always have to provide all the data to AddOrUpdateAccount(), such as the |is_under_advanced_protection| bit.

For instance, as I found out in the context of  crbug.com/913392 , in InlineSigninHelper::OnClientOAuthSuccessAndBrowserOpened() there's a call to UpdateCredentials [1] that, when translating to AddOrUpdateAccount(), will force us to pass a value for |is_under_advanced_protection| that was not there in the original code. If the account did not exist before then it will be fine to pass |false| there, but if it exists (not sure if that could happen in that context, though) then passing |false| could potentially change the previous value, which we don't know which one it is at this moment (and we can't know since there's no API in IdentityManager & friends to retrieve the list of seeded accounts without a refresh token assigned yet).

This makes me think that perhaps we might want to consider this when analyzing this situation.

It might be that, while looking for the right solution here, we also want to consider a "lighter" version of AddOrUpdateAccount() where we only need to specify the refresh token + a way to identify the account (either an account ID or the combination of gaia & email we currently have).

[1]https://cs.chromium.org/chromium/src/chrome/browser/ui/webui/signin/inline_login_handler_impl.cc?pv=1&l=341

Well, to be fair, in the particular case of InlineSigninHelper::OnClientOAuthSuccessAndBrowserOpened() I can actually pass |result.is_under_advanced_protection| (see |struct ClientOAuthResult|), but still I think it's worth considering whether we always want to force passing all the possible information needed to "Add" an account when we're just "Updating" :-)

Hi Mario,

Thanks! I think that we should enforce passing all info at this point, based on the data point that the lack of setting this state in this case was apparently a bug.

Sounds good. I was a bit hesitant on that and decided it was better to double-check this was the intention, rather than assuming. Thanks for confirming!