[Core HTTP] Token refresher is not shared among multiple requests
See original GitHub issuePR https://github.com/Azure/azure-sdk-for-js/pull/10085 introduced a change in core-http in which new requests might trigger delayed token refreshes. These delayed requests might take more time than the tests take to finish, ending up resolving after the recorder wraps up on the afterEach. Here’s some form of diagram:
BEFORE
All test requests finished before the test finished
1 Request -> 1 Entry in the recording file
AFTER
Some requests might happen asynchronously
1 requests before the test finishes -> 1 Entry in the recording file
1 Delayed request -> No entry in the recording file
This causes the playback runs to show requests that failed, since playback can’t find the recording. However: the test themselves don’t fail, because they completed successfully before this delayed request happened.
One interesting thing is that playback is able to see these extra requests happening, but recording does not. I’m not sure how useful is that.
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
Top Results From Across the Web
.net - Issue with JWT token multiple simultaneously refresh ...
Client make requests with JWT. When Axios interceptor gets 401, then try to refresh tokens with generated below Refresh Token. Used Refresh ......
Read more >What Are Refresh Tokens and How to Use Them Securely
This post will explore the concept of refresh tokens as defined by OAuth 2.0. We will learn how they compare to other token...
Read more >Building a concurrency-proof token refresh flow in Combine
Refreshing access tokens is a common task for many apps that use OAuth or other authentication mechanisms. No matter what your ...
Read more >Using Refresh Tokens in ASP.NET Core Authentication
With refresh token -based flow, the authentication server issues a one-time use refresh token along with the access token. The app stores the ......
Read more >Refresh Tokens in ASP.NET Core Web Api - The Blinking Caret
When a request fails because of an expired access token, a new request should be sent to a refresh endpoint with the access...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
With #10728, there would be no delayed requests(such as the ones happening after the test) which is what this issue is originally created for. It is logically possible to have such request after the test, but with the current configuration of 30s limit for the token refreshing, it is highly unlikely that our tests would hit the issue. Also, the time taken for the tests would be different in record vs playback modes, which would mean the token refreshing that might happen in record won’t happen in playback. Given the above, we won’t be adding any support to record the requests that are beyond the test(happening outside the test run).
Updated the label and the title to reflect the current status of investigation.