@sethterashima can I ask you to look into this issue? Its still unclear how to create long-running applications to handle access token expiry. It seems the idiomatic way doing this would be using an oauth2.TokenSource which #24 suggest.
Is this on the roadmap or do you expect library consumers to use account.New() on token expiry?

Friendly ping. This is an absolut blocker for any long-running application. How are applications supposed to perform token refresh with the current capabilities?

@andig
Hi, maybe have a look at my implementation .
I just check, if I have to refresh the access token right before using it.
If it is expired I do a token refresh with the refresh token.
Or do I not get the question?

I just check, if I have to refresh the access token right before using it.

@fabianhu that's exactly what a Golang TokenSource does and is implemented in #151. Point here is that the Account is presumably something long-lived. That is not possible if it works on a static token.

Imho this proposal is a more go-ish and fully-featured way of doing things.

@andig Hi, maybe have a look at my implementation . I just check, if I have to refresh the access token right before using it. If it is expired I do a token refresh with the refresh token. Or do I not get the question?

Currently I can only refresh tokens during +/- 24h ... after that, refreshing token returns 401 and I'm forced to login again to get a new CODE and then a new token/refresh_token

Does anyone know if I'm doing something wrong?
Current refresh logic - https://github.com/codesquadnest/tesla-smart-charger/blob/main/tesla_smart_charger/cron/token_cron.py

@andig are you aware of this issue?

Currently I can only refresh tokens during +/- 24h ... after that, refreshing token returns 401 and I'm forced to login again to get a new CODE and then a new token/refresh_token

When refreshing access tokens make sure to store the new refresh token, too.