It is important to note that updating the token does not create a new instance: the value of "access_token" changes, the old value of the key stops working. This can lead to problems when working with the API in multiple threads: two threads can simultaneously detect that the token has expired and send an update request. The request that comes first will update the token and start using it, while the second thread will update the token again and the first thread will try to use an already nonexistent token.
One solution to this problem is to catch an error about a nonexistent token in the first thread and retrieve the token anew from a thread-shared repository – for example, a database where each thread writes the token after an update. You should also take into account that the record in the store can also be competitive, and use, for example, locks.
Another solution to this problem might be to enable the "refresh_token" update option on each "access_token" update. Then the first thread will update both "access_token" and "refresh_token", and in the second you need to handle the error about the unknown "refresh_token" and re-read "access_token" from the repository. But when updating "refresh_token" you must keep its most recent value, otherwise you will no longer be able to update "access_token", and will have to write out a new one. This OAuth client option can now only be enabled on a support request (firstname.lastname@example.org
Another option is to proactively update all expiring tokens. It is that you need to regularly check if you have any tokens expiring, for example, in the next half hour, and update them in the background process. But if you combine it with real-time updates in workflows, you still have to handle errors because of possible conflicts.