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