FERRT errors from getTokenSilently intermittently during concurrent requests

I shared this on the community forums already, but figured, this might be a better place for reporting if it a bug.

Describe the problem

Concurrent calls to getTokenSilently can allow multiple locks to be acquired causing FERRT errors if the access token in the cache has expired.

What was the expected behavior?

getTokenSilently prevents multiple concurrent from acquiring multiple locks.

Reproduction

Unfortunately, this is tough to reproduce as it is intermittent, but I was able to using the SPA SDK playground. I changed the getToken function in the playground to call the getTokenSilently method 15 times. I’m sure there is more aggressive configuration combination that might error quicker, but while debugging what we were experiencing, I was trying to stay as true to our application’s situation as possible. Essentially, I tried to wait until the access token was going to expire and start consistently pressing the “Get Access Token” button.

Auth0 API Audience: my.domain.com Access Token Expiration: 70s

Application Refresh Token Behavior - Rotating Refresh Token Lifetime - 36000 Refresh Token Reuse Interval - 30

Playground Audience - my.domain.com Use local storage - true Use refresh tokens - true Use token cache when fetching new tokens - true Use Auth0Client constructor - false

Environment

• Version of auth0-spa-js used: 1.11.0
• Which browsers have you tested in? Firefox 79, Safari 13.1.2

Screenshots

[stevehobbsdev]

@egadstar 👋 just checking in to say that we are continuing to find a solution for this, I’ll tag the PR here when we have something.

[adamjmcgrath]

Hey @egadstar - I’ve had a look at the issue and I’m able to reproduce it.

The problem occurs when acquiring the lock times out. If the async operation takes about 500ms, and you queue up 15 operations instantly. The 11th operation will have been waiting for ~5.5secs (500ms * 11).

Since the lock times out after 5 secs. The 11th and subsequent 3 in the queue will all be allowed to pass at the same time. If during this time your access token has expired, you will see one of those calls succeeding and the others failing with FERRT errors.

I’ve put a branch here that demonstrates the problem https://github.com/auth0/auth0-spa-js/compare/locks-test

Run for (let i = 0; i < 16; i++) { auth0.getTokenSilently() } and in the console you will see something like:

num locks:  1 , last token acquired:  true , ms waited:  586
num locks:  1 , last token acquired:  true , ms waited:  1179
num locks:  1 , last token acquired:  true , ms waited:  1774
num locks:  1 , last token acquired:  true , ms waited:  2359
num locks:  1 , last token acquired:  true , ms waited:  2949
num locks:  1 , last token acquired:  true , ms waited:  3540
num locks:  1 , last token acquired:  true , ms waited:  4130
num locks:  1 , last token acquired:  true , ms waited:  4721
num locks:  7 , last token acquired:  true , ms waited:  5314 <= after 5secs
num locks:  6 , last token acquired:  false , ms waited:  5507
num locks:  5 , last token acquired:  false , ms waited:  5509
num locks:  4 , last token acquired:  false , ms waited:  5508
num locks:  3 , last token acquired:  false , ms waited:  5508
num locks:  2 , last token acquired:  false , ms waited:  5508
num locks:  1 , last token acquired:  false , ms waited:  5508

Obviously if the server response times are slower, you will need to hit this less frequently to reproduce it - but you will always need the token to expire while you’re making multiple requests, which makes this hard to reproduce (adding ignoreCache: true would make it easier to reproduce)

I’ll have a chat with my team and look in our logs to see how common FERRT errors are with the SPA JS client.