@@ -293,9 +293,28 @@ Gargle2.0 <- R6::R6Class("Gargle2.0", inherit = httr::Token2.0, list(
293293 )
294294 if (is.null(cred )) {
295295 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().
299318 self $ credentials $ refresh_token <- NULL
300319 } else {
301320 self $ credentials <- cred
0 commit comments