You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current design of this client library, I believe there is a possibility of multiple refreshes and race conditions when parallel requests are made. This problem can be solved by changing the function signature to the following and passing the TokenSource from outside. (I understand that this is a big change.)
Yes, you are correct. This library does not support parallel updates.
If the Token is updated at the same time, one request will be updated in the state of the old Token .
(and TokenSource should be concurrency-safe because it called at Transport.RoundTrip())
We plan to change the function signature when updating a major version in the near future.
Thanks for publishing an easy-to-use client library! I was wondering about the API design for actual use.
In the current code, it seems that
oauth2.TokenSource
is created for each request.freee-go/client.go
Line 159 in 4609d30
The internal implementation of
oauth2.TokenSource
,oauth2.reuseTokenSource
, checks to see if the token is currently valid, and if not, it reclaims and updates the token. It is then serialized by Mutex.https://github.com/golang/oauth2/blob/d3ed0bb246c8d3c75b63937d9a5eecff9c74d7fe/oauth2.go#L295-L310
With the current design of this client library, I believe there is a possibility of multiple refreshes and race conditions when parallel requests are made. This problem can be solved by changing the function signature to the following and passing the TokenSource from outside. (I understand that this is a big change.)
What are your thoughts on these issues?
The text was updated successfully, but these errors were encountered: