Fixes a very unique scenario described in https://github.ibm.com/arf/planning-sdk-squad/issues/2149. In the scenario where a client has been idle passed the refresh time, but before expiration time, the previous logic would result in multiple goroutines being kicked off attempting to request a new token until a new token was fetched or until the refresh time caught up to the current time. I've updated the new refreshTime calculation to be 1 minute ahead of the current time vs 1 minute ahead of the previous refreshTime value.
Java also probably has this same issue so I will update that core as well.
Fixes a very unique scenario described in https://github.ibm.com/arf/planning-sdk-squad/issues/2149. In the scenario where a client has been idle passed the refresh time, but before expiration time, the previous logic would result in multiple goroutines being kicked off attempting to request a new token until a new token was fetched or until the refresh time caught up to the current time. I've updated the new
refreshTime
calculation to be 1 minute ahead of the current time vs 1 minute ahead of the previousrefreshTime
value.Java also probably has this same issue so I will update that core as well.
ref: https://github.ibm.com/arf/planning-sdk-squad/issues/2149