-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: adds forceRefreshOnFailure flag, for refreshing token on error #790
feat: adds forceRefreshOnFailure flag, for refreshing token on error #790
Conversation
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
CLAs look good, thanks! ℹ️ Googlers: Go here for more info. |
👋 @skeggse thanks for the contribution 👍 I have it on my plate this week to dig into why the heck refresh token logic sometimes fails, I'll get back to reviewing this once I've done a bit of a deep dive on the functionality. |
I think this is still useful, and would like to see a solution similar to this one that doesn't depend on local state (like the system clock). I'd also like to avoid refreshing unless we get a signal that the token may not be up to date, as our analysis indicates that multiple api clients refreshing the token can result in some of the access tokens being invalid - we've implemented a bunch of extra locking around the token refresh process to work around this. |
@skeggse how would the locking be facilitated in this case, you'd only have one of your clients configured to refresh, and several with no eager refresh or |
@bcoe we extend the Funny enough, our solution actually fairly well mirrors the approach proposed by the OP of #41. |
@skeggse, I'm open to this feature, but I don't quite understand the flag |
Sounds good to me! The flag just means that we should refresh the token in lazy cases, but your flag is far clearer. |
It's highly unlikely, but the expiry_date could be wrong, or the comparison in isTokenExpiring could fail due to an inaccurate system clock. As a further fallback behavior, some developers may wish to opt- in to attempting a refresh if Google's servers respond with a status code that may indicate the token has expired.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
awesome, I'll work on landing this soon.
Codecov Report
@@ Coverage Diff @@
## master #790 +/- ##
==========================================
+ Coverage 84.52% 84.54% +0.01%
==========================================
Files 17 17
Lines 950 951 +1
Branches 211 211
==========================================
+ Hits 803 804 +1
Misses 87 87
Partials 60 60
Continue to review full report at Codecov.
|
@skeggse I want to use this later today as an example of how our release process works, it's not actually blocked by anything on your end 👍 |
@bcoe awesome, love it! |
It's highly unlikely, but the
expiry_date
could be wrong, or the comparison inisTokenExpiring
could fail due to an inaccurate system clock. As a further fallback behavior, some developers may wish to opt-in to attempting a refresh if Google's servers respond with a status code that may indicate the token has expired.