@@ -293,9 +293,28 @@ Gargle2.0 <- R6::R6Class("Gargle2.0", inherit = httr::Token2.0, list(
293
293
)
294
294
if (is.null(cred )) {
295
295
token_remove_from_cache(self )
296
- # TODO: why do we return the current, invalid, unrefreshed token?
297
- # at the very least, let's clear the refresh_token, to prevent
298
- # future refresh attempts
296
+ # It's tricky to decide what to do here. Currently we return the current,
297
+ # invalid, unrefreshed token, but we clear the refresh_token field, to
298
+ # prevent subsequent refresh attempts.
299
+ #
300
+ # Analysis from a BYO token POV:
301
+ # I've decided the status quo may be the best move, because it causes
302
+ # token_fetch() to return instead of moving on to try other methods. If
303
+ # someone provides token_fetch(token =), I think it's clear that they
304
+ # want/hope to use that token and they don't want to end up doing the
305
+ # OAuth browser dance. If we threw an error or returned NULL,
306
+ # token_fetch() would just keep going. The refresh failure does throw a
307
+ # visible warning:
308
+ #
309
+ # Warning message:
310
+ # Unable to refresh token: invalid_grant
311
+ # • Token has been expired or revoked.
312
+ #
313
+ # However, this does mean that functions like PKG_has_token() still return
314
+ # TRUE and that some other method must be used to find out if we have a
315
+ # *valid* token. gargle::token_tokeninfo() and API-specific functions for
316
+ # "tell me about the current user" are good candidates, such as
317
+ # gmailr::gm_profile() or googledrive::drive_user().
299
318
self $ credentials $ refresh_token <- NULL
300
319
} else {
301
320
self $ credentials <- cred
0 commit comments