IdentityManager: Fix timing of token update observer callbacks
This CL fixes a timing issue with the implementation of
IdentityManager::Observer::OnRefreshTokenUpdatedForAccount():
- It is fired from IdentityManager::WillFireOnRefreshTokenAvailable()
- which is fired from
ProfileOAuth2TokenService::OnRefreshTokenAvailable()
- just *before* ProfileOAuth2TokenService calls
CancelRequestsForAccount().
The upshot is that any access token requests made from
IdentityManager::Observer::OnRefreshTokenUpdatedForAccount()
implementations will be immediately cancelled. Yikes! On desktop, it
also means that access token requests that are made from
ProfileOAuth2TokenService::Observer::OnRefreshTokenAvailable() clients
after any such cancellations will also be cancelled, as
MutableProfileOAuth2TokenServiceDelegate has a policy of immediately
canceling access token requests for some amount of time after it has
seen a cancelled access token request (this is part of its backoff
policy).
The fix is the following:
- Move the firing of the IdentityManager::Observer callbacks to its
(new) implementation of the corresponding
OAuth2TokenService::Observer callbacks.
Note that the updating of IdentityManager's internal state must still
be done in IdentityManager::WillFireOnRefreshToken{Available, Revoked};
this ensures that it updates its state before any observers of
ProfileOAuth2TokenService are notified of the state change, and thus
that any such observers see a consistent state between IdentityManager
and ProfileOAuth2TokenService. To decouple the internal update from
the firing of the observer callbacks, some state is now saved from
the internal updates firing to forward in the observer callbacks.
This change is unittested via extensions to the
PrimaryAccountAccessTokenFetcher unittests that ensure that the fetcher
does not have a request cancelled that is made in its implementation of
IdentityManager::Observer::OnRefreshTokenUpdatedForAccount(). Before
the production fix, the extended unittests would have failed, as the
fetchers were seeing a cancelled request and then retrying it (which
succeeded).
Bug: 869376
Change-Id: Ic5d3208ef893ad0e821c38bbb88c713d68042a1a
Reviewed-on: https://chromium-review.googlesource.com/1152731
Commit-Queue: Colin Blundell <blundell@chromium.org>
Reviewed-by:
Mihai Sardarescu <msarda@chromium.org>
Cr-Commit-Position: refs/heads/master@{#579813}
Showing
Please register or sign in to comment