Auto-refresh auth tokens.

[ruseinov]

It might actually be beneficial to auto-refresh tokens by checking if they are close to expiration as having to spawn a separate thread for that seems laborious.

The current approach I've taken is as follows:

pub fn init_pubsub() -> cloud_pubsub::Client {
    ....

    let client = cloud_pubsub::Client::new_with_string(pubsub_credentials).unwrap();
    let refresh_client = client.clone();
    spawn(lazy(move |_ctx| {
        refresh_client.spawn_token_renew(GOOGLE_TOKEN_REFRESH_INTERVAL)
    }));
    client
}

But I can't imagine a scenario where one would not want to refresh token when it expires, nor do I think it's an implementation detail that the library user should care about.

What we could do is check token expiration on request and if it's close to be expired - spawn renew it right there and then.
It just has to be implemented in a performant way.

I do understand why the current approach has been taken: it makes the library easier to read and understand, but I'm sure we can come up with a solution that would work just as well without the extra burden on the user's side.

[kayleg]

I would love to hide this away - it was purely just the easiest path to get this going when I created the package.

If possible, I would like to maintain that the Token is always ready for use when fetching or publishing so those requests are not delayed.

[ruseinov]

I'm guessing this means we still want to do this in a different thread then. Since you depend on a full version of tokio that should not be a problem, although that would require the runtime to be present, otherwise it'd panic.

[kayleg]

We could also have it feature based. So you could enable preemptive (just a working feature name) renew which would spawn a separate tokio task to monitor the token status. Or non-preemptive which would check after a request if the token is about to expire and spawn the renew task as well as check if the token has expired before firing the main request.

[ruseinov]

sounds good, feature names would need some work indeed. Naming is always hard!