our users are working around the problem by clearing all site data in their browser's dev tools, and that allows them to go back through the login process & regain access to the app. this makes it sound like a local state issue with the site/SDK?

Just thinking aloud: so if there is another request that's already refreshed the session, whilst the previous one got 401 try refresh token, then the previous one would not call the refresh API. But it should call the original request again. But i guess this is not the situation since users should not notice this anyway

another reason is that the locking mechanism (that happens before a refresh is called) is failing somehow such that it never successfully acquires the lock. This way, a refresh API would never be called.

> if there is another request that's already refreshed the session the HAR file captured all network traffic from the start of the site loading. there are no logged HTTP requests to refresh the session.

hmmm

or do you mean another request that ran previously, during a different session?

no. the same session. But perhaps a different browser tab

i think the issue is to do with the locking..

which can be solved by clearing its key in localstorage

this is running inside an Electron 13 app. there's only a single renderer process (or "browser tab").

hmmmm

locking issues can still happen within one tab

but Auth0 uses our locking lib as well.. and if they haven't complained about it, then it seems unlikely that that's the issue.

are you able to replicate it at all?

the users were only able to provide HAR files, and i don't have any other cookie or local storage state.

i am not. out of thousands of daily active users... it only affects about a dozen per day.

hmmmm

could it be an issue with the env the Electron app is running in - for these users.

but it's consistent enough. our community support team on Discord now has this documented as a "known issue", and they just run users through clearing site data and having the user login again.

a smaller percentage of users access our site through their web browsers. i have yet to receive a report of this occurring that explicitly identified it happening in a browser. but stats-wise... it's much more likely to hear of issues in the Electron app anyway. that's how most people use our product.

Can you ask them to clear just the localstorage key that starts with "browser-tabs-lock-key" and then reload the page?

cause if this solves the issue for them, then i know that it's 100% a locking issue.. else it's 100% not a locking issue.

perfect. yes, i will relay this to the team. i will get back to you after they get an opportunity to run it by a user.

sounds good! thanks

so if the key is missing in the localstorage when this issue is faced, then also we know that it's not a locking issue. So it's an issue only if the key is there, the user deletes that key, and reloads the app (though just deleting should be enough), and then it starts to work

What about in a plesk installation?

Is there a ui to this or mostly cli

Jw

does plesk use chromium?