Here's what we've identified thus far: 1. /auth/session/refresh fails with a 401 on login page (probably expected) 2. User attempts to login, we do a migration from our previous auth system (can provide details on how this is done if needed, but mostly straightforward and we've found that the migration works as we expect). 3. On the frontend, we see the result of a successful http call to /signin, BUT it seems

emailPasswordSignIn

throws an error. Unfortuately we do not have adequate logging here to know what the details of the error was, but we do know err.isSuperTokensGeneralError was false. 4. Within ThirdPartyEmailPassword.getRedirectionURL, context.action === 'SUCCESS', as we redirect to the OTP screen on this condition. 5. We then see /user/email/verify retrying indefinitely, and entering the OTP code and hitting submit has no effect. 6. Eventually we see a bunch of errors printed to the console:

Encountered an error while refreshing validator st-ev[object Response]
    Uncaught (in promise): Error: No session exists

A couple of immediate questions that would be really helpful for us: 1. Broadly, any ideas here on where we should be looking to debug this further? We've taken a look at all the backend HTTP calls and a bunch of fe SDK code. Its obvious theres an error being throw here - https://github.com/supertokens/supertokens-website/blob/e7c136fbbb6a659e8cd2942486fcb9266064ad46/lib/ts/recipeImplementation.ts#L82 -, but without context its hard to tell what's going on in our case. 2. What does the SDK do in the background in between the /signin call, and firing of getRedirectionURL? It seems the error (which assumingly is triggering the indefinite reties) occurred somewhere in here.

what is the API input / output in this case? Specifically, request and response headers and the http status code. Which SDKs of ours are you using, and which versions? Finally, are you using our pre built UI or custom UI?

And also, what happens after this api is called? Does it get called again - and is that what you meant by retrying indefinitely?

Since you are using custom ui for emailverification, what’s the condition on which you call this api?

Also, can you send the value of sAccessToken from the cookie storage? (You can dm this to me)

And also the value of sFrontToken from the cookie storage

Can you send the value of front-token across API calls? Also, the front-token is present in the response headers, but can you also fetch its value from cookie storage?

Another reason this could be happening is that

<EmailVerify />

component might be constantly remounting.

If that component remounts, it implies that our email verification component (which embeds your

<EmailVerify />

component), is also remounting and that component calls the email verify GET API. So any reasons that might be causing remounts?

looking now to see if that's our code or supertokens SDK code

Regardless, if the frontend's clock is in the future compared to the backend's clock, that would cause issues like this where our frontend SDK would try to call the email verification get API indefinitely (assuming that the frontend is at least 5 mins ahead of the backend)

There are ways to measure this skew and take it into account though. We will add this to our roadmap.

but for now, you could just increase the

maxAgeInSeconds

to make it 10 mins instead of 5 mins. Making this an even more rare edge case. That is until we can implement the skew check logic.

Try this on the frontend's session.init in the recipeList in supertokens.init:

ts
import EmailVerification from "supertokens-auth-react/recipe/emailverification";
import Session from "supertokens-auth-react/recipe/session";

Session.init({
    override: {
        functions: (oI) => {
            return {
                ...oI,
                getGlobalClaimValidators: function (input) {

                    // we remove the default claim validator which has maxAgeInSeconds as 5 mins
                    input.claimValidatorsAddedByOtherRecipes = input.claimValidatorsAddedByOtherRecipes.filter(c => c.id !== EmailVerification.EmailVerificationClaim.id);

                    // then we re add it with 10 as the max age in secs
                    input.claimValidatorsAddedByOtherRecipes = [...input.claimValidatorsAddedByOtherRecipes, (EmailVerification.EmailVerificationClaim.validators as any).isVerified(10, 600)]

                    return input.claimValidatorsAddedByOtherRecipes;
                }
            }
        }
    }
})

In

.isVerified(10, 600)

, the

10

represents the minimum number of seconds to wait for before querying the is email verification API if the email is NOT verified, whereas

600

is the min number of seconds to wait for if the email is verified. The default values in our SDKs are

(10, 300)

.