Repository navigation
Conversation
expiration_time_millis is nil; fall back to 0expiration_time_millis is nil; fall back to 0
sampart
force-pushed
the
expires-at-handle-nil
branch
from
December 3, 2025 14:07
3d80798 to
3f1709d
Compare
|
The change seems fine but tests are failing, possibly because the branch is so old. Can you rebase on main and push again? |
…ck to 0
`data.fetch("expiration_time_millis", 0)` will default to 0 only if the key is not present. If the key is present but the associated value is nil, then prior to this change the code would raise as follows:
```
NoMethodError (undefined method `/' for nil:NilClass
expires_at: data.fetch("expiration_time_millis", 0) / 1000
^):
```
This commit updates the code to default to 0 if the key is not found or if the value is nil.
With the existing token stores, this situation may not arise, but it's a particular issue when using a custom token store where values could be nil, like a database.
sampart
force-pushed
the
expires-at-handle-nil
branch
from
October 13, 2026 13:20
3f1709d to
145b832
Compare
Contributor
Author
|
Thanks @amanda-tarafa. Done 👍 |
amanda-tarafa
approved these changes
Oct 13, 2026
Member
|
Adding |
| access_token: data["access_token"], | ||
| refresh_token: data["refresh_token"], | ||
| expires_at: data.fetch("expiration_time_millis", 0) / 1000 | ||
| expires_at: (data.fetch("expiration_time_millis") || 0) / 1000 |
There was a problem hiding this comment.
Using fetch without a default will raise a KeyError if the key missing, could we instead do:
expires_at: (data["expiration_time_millis"] || 0) / 1000Furthermore, could you also add a couple of unit tests covering both the nil and missing key cases in spec/googleauth/user_authorizer_spec.rb? That way we can avoid regressions.
Member
There was a problem hiding this comment.
This is what I was concerned about as well.
There was a problem hiding this comment.
Oh yes, agreed, I didn't "see" that the default was being removed, just saw the coalescing bit.
amanda-tarafa
requested changes
Oct 13, 2026
robertvoinescu-work
requested changes
Oct 13, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The change
data.fetch("expiration_time_millis", 0)will default to 0 only if the key is not present. If the key is present but the associated value is nil, then prior to this change the code would raise as follows:This commit updates the code to default to 0 if the key is not found or if the value is nil.
With the existing token stores, this situation may not arise, but it's a particular issue when using a custom token store where values could be nil, like a database.
Testing
Since the existing tests don't cover the existing fallback, I've not added to them here either.
I've tested this change manually locally by modifying my copy of the gem in a test project.
Changelog
https://github.com/googleapis/google-auth-library-ruby/blob/main/.github/CONTRIBUTING.md mentions updating the CHANGELOG. However, CHANGELOG updates now appear to be an automated process so I've left this alone.