UbertokenFecther should invalidate access token if it's invalid.

UbertokenFecther should invalidate access token if it's invalid.
Add retry with backoff to invalidate only for non-transient errors.

BUG=416612
Committed: https://crrev.com/b6fc75671249eb039ad6937e87d145b3d68c7a71
Cr-Commit-Position: refs/heads/master@{#296992}

[Roger Tawa OOO till Jul 10th, 2014-09-25 00:18:47]

Patchset #2 (id:20001) has been deleted

[Roger Tawa OOO till Jul 10th, 2014-09-25 00:18:57]

Patchset #1 (id:1) has been deleted

[Roger Tawa OOO till Jul 10th, 2014-09-25 00:19:05]

Patchset #1 (id:40001) has been deleted

[Roger Tawa OOO till Jul 10th, 2014-09-25 00:22:27]

Patchset #1 (id:60001) has been deleted

[Roger Tawa OOO till Jul 10th, 2014-09-25 15:28:43]

rogerta@chromium.org changed reviewers:
+ guohui@chromium.org

[Roger Tawa OOO till Jul 10th, 2014-09-25 15:28:43]

Hi Hui,

Following up on our discussion after the simplification of the reconcilor.  The
uber-token fetcher will now invalidate the oauth2 access token on non-transient
failures.  I also added retries with exponential backoff to handle transient
failure to make the reconciliation more robust.  I'll look at add retries to
MergeSessionHelper in a separate CL.

[Roger Tawa OOO till Jul 10th, 2014-09-26 03:46:14]

Hi Hui,

As discussed, a non-transient failure will invalidate the access token and try
one more time just in case the problem was a cached, expired token.  Please take
another look.  Thanks,

[guohui, 2014-09-26 17:22:31]

lgtm with one question.

https://codereview.chromium.org/597003002/diff/150001/google_apis/gaia/uberto...
File google_apis/gaia/ubertoken_fetcher.cc (right):

https://codereview.chromium.org/597003002/diff/150001/google_apis/gaia/uberto...
google_apis/gaia/ubertoken_fetcher.cc:70: } else {
can we distinguish the cases 1) both refresh token and access token are invalid,
2) access token is invalid but refresh token is valid. It seems useless to send
a second access token request in the first case.

[Roger Tawa OOO till Jul 10th, 2014-09-26 17:49:55]

Thanks Hui.  Implemented minor change to RequestAccessToken() we discussed.

https://codereview.chromium.org/597003002/diff/150001/google_apis/gaia/uberto...
File google_apis/gaia/ubertoken_fetcher.cc (right):

https://codereview.chromium.org/597003002/diff/150001/google_apis/gaia/uberto...
google_apis/gaia/ubertoken_fetcher.cc:70: } else {
On 2014/09/26 17:22:31, guohui wrote:
> can we distinguish the cases 1) both refresh token and access token are
invalid,
> 2) access token is invalid but refresh token is valid. It seems useless to
send
> a second access token request in the first case.

Opened bug https://crbug.com/418158 to track this.

[Roger Tawa OOO till Jul 10th, 2014-09-26 17:50:03]

The CQ bit was checked by rogerta@chromium.org

[Roger Tawa OOO till Jul 10th, 2014-09-26 17:50:20]

The CQ bit was checked by rogerta@chromium.org

[commit-bot: I haz the power, 2014-09-26 17:51:13]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/597003002/170001

[commit-bot: I haz the power, 2014-09-26 18:55:29]

Committed patchset #6 (id:170001) as 72f4f4bd0f046ada61cbda6abdc4d2e0ea7f26c6

[commit-bot: I haz the power, 2014-09-26 18:56:10]

Patchset 6 (id:??) landed as
https://crrev.com/b6fc75671249eb039ad6937e87d145b3d68c7a71
Cr-Commit-Position: refs/heads/master@{#296992}