Timeout error in getTokenSilently (that happens instantly) starting with 1.13

[nickroyerUBC]

We're getting a timeout error in getTokenSilently (that happens instantly) when using different versions of the auth0 spa js package. I tried to reproduce in one of the quickstarts however we weren't able to reproduce it in the simpler environment.

-- We load from the CDN:
https://cdn.auth0.com/js/auth0-spa-js/1.13/auth0-spa-js.production.js

1.12 & 1.12.1 -> Works exactly as expected

1.13 -> Has timeout error

1.13.1 -> 1.13.4 works exactly as expected

1.13.5 & 1.13.6 throws timeout error

1.14 still throws the error
I can test other versions as necessary

Due to external constraints this app is required to use promises instead of async / await

This is the relevant code: (NOTE: While testing I also tried to initialize via createAuth0Client however the same error occurred)

    const auth0 = new Auth0Client({
        domain: connector.IdentityConnector.Authority,
        client_id: connector.IdentityConnector.ClientId,
        redirect_uri: connector.IdentityConnector.RedirectUrl
    });
    if (auth0 === undefined)
        return false;

    hasAuth0 = true;
    connector.Auth0.App = auth0;

    connector.Auth0.App.getTokenSilently({}).then(function (token) {
        connector.Auth0.LoginHandler(token);
    }).catch(function (error) {
        if (error.error !== 'login_required') {
            console.error(error);
            //On error notify the identity service
            processLogin(connector, undefined, undefined);
        }
    });

Auth0Service.js:88 Error: Timeout
at n [as constructor] (errors.ts:3)
at new n (errors.ts:34)
at e. (Auth0Client.ts:691)
at tslib.es6.js:99
at Object.next (tslib.es6.js:80)
at c (tslib.es6.js:70)

Originally posted by @nickroyerUBC in #706 (comment)

[qortex]

+1
That may explain an error that I suspect occurs client-side in prod and I can't trace it (after a call to loginWithPopup).

[stevehobbsdev]

Thanks for reporting @nickroyerUBC. The way the CDN works, using 1.13 will actually give you the latest patch version, which is 1.13.6. So it looks like something got introduced in 1.13.5 that might have caused this, reading your bug report.

Let me look into it. In the meantime, could you let me know what browser you're testing this in? Also, when you say "the simpler environment", do you mean the SDK Playground? If not, have you tried to reproduce it in the playground?

[nickroyerUBC]

I've been testing primarily in Chrome (version 89), however I did validate that the error occurs for us in Firefox as well.

I have not tried to reproduce the SDK playground yet (will try that soon)

I did try to reproduce using one of the SPA sample applications (which unfortunately has not reproduced the issue yet)

[stevehobbsdev]

@nickroyerUBC I'm unable to reproduce this. I've put up an example of what I'm running in this Gist, if you could give that a try and see if it works for you.

It's based on your example code above but I've taken your app-specific bits out.

[nickroyerUBC]

I unfortunately haven't been able to reproduce this issue yet in any of the simpler test cases ( so there is likely some issue with includes). I have identified however that the timeout is happening here in 1.13.5

if (
  await retryPromise(
    () => lock.acquireLock(GET_TOKEN_SILENTLY_LOCK_KEY, 5000),
    10
  )

This attempts to get the lock 10 times in quick succession and then fails so it throws the timeout exception

[nickroyerUBC]

I've added some console logging to the auth client and merged it into my environment. I believe the reason may be that the lock was never actually checked for a successful result previously and in the new version it has to return success or else it retries 10 times (always failing)

[stevehobbsdev]

This attempts to get the lock 10 times in quick succession and then fails so it throws the timeout exception

We use a third-party to perform that logic (locking across tabs) and it looks like it's returning immediately because it can't get a lock. Any errors other than timeout in the console? Have you tried clearing local storage/cookies/cache etc or running in Incognito mode?

It's true that prior to 1.13.5 we were (incorrectly) not waiting for a result but implemented that for good reason. Debugging the problem you're seeing is proving difficult. Please let us know if your console logs yield any insight.

[nickroyerUBC]

I believe I've found the issue:

Our platform is using this js package: https://github.com/datejs/Datejs

which has the following prototype:
Date.now = function () {
return new Date();
};

which breaks the package: https://github.com/supertokens/browser-tabs-lock

you should be able to add that script to reproduce the issue I'm seeing.

[stevehobbsdev]

Thanks @nickroyerUBC, glad you have found the issue. I would then contact the authors of browser-tabs-lock to let them know they have an incompatibility with this package.

Closing this for now as doesn't appear to be an issue with the SDK, but happy to continue the conversation.