Hi, I'm having trouble updating the access token payload for multiple sessions. I have variable called

verified

in the access token payload which is set during session creation. At a later time when I want to update this value for all sessions with a given userId, I am doing the following:

async function updateAllAccessTokenPayloads(uuid, data) {
    const handles = await getAllSessionHandlesForUser(uuid);
    for (let i = 0; i < handles?.length; i++) {
        await mergeIntoAccessTokenPayload(handles[i], data);
    }
}

On the frontend, I'm getting inconsistent results: After calling

mergeIntoAccessTokenPayload

on each session handle, it doesn't always update the session on the frontend. I noticed that after refreshing the page in Chrome, the supertokens api

/session/refresh

is called every time. But not in other browsers (Edge, Firefox). This

/session/refresh

call causes the frontend to cycle through 2-3 JWTs, some with the correct

verified

value, some unchanged. In Firefox/Edge, the

/session/refresh

call doesn't happen on a page refresh, and it seems to be unaffected by the

mergeIntoAccessTokenPayload

call. I'm continuing with testing to better understand what's happening, but I'm wondering if there's anything wrong with my use of

mergeIntoAccessTokenPayload

. Should these session changes be reflected in the

useSessionContext()

token payload on the frontend after a page refresh? Edit: Until the frontend automatically calls

/session/refresh

, the frontend is using an out of date token payload. After calling

session/refresh

, it has the updated payload.

Hey @Bailey

No SSR. When should the frontend learn that the payload has updated? It only seems to happen after

/session/refresh

is called, but this is only occurring in chrome and it shouldn't be calling it on a page reload. What could cause the frontend to call

/session/refresh

?

The front end would know that the payload is updated after a call to the refresh api

I'm using EmailVerification, EmailPassword, Passwordless for 2fa, and Session

Right. So this seems fine

None return a 401, I'm currently testing on a blank page that just lets me call the backend to make the request to change the token payload. I'm getting different results though because the /refresh route isn't being called on this page. Trying to figure out what is causing that to be called

hmmm. If you are using the supertokens-auth-react SDK, try wrapping this page with the wrapper - what happens?

If I use session auth around one of the normal routes I have this problem with it seems to act the same. And when I use it around my test route it doesn't do anything different there either.

interesting.

The logs I could send are a bit messy. I'm currently trying to reproduce the issue I'm seeing on a test page so that the logs are only updating as needed to reproduce the issue

Okay!

Thank you, i'll message back here once I have some more info

Also, tagging in @porcellus here who might be able to help as well

Not sure how useful these logs will be. This was an example where the frontend received multiple JWTs. I can't figure out how to consistently reproduce this issue, but I am seeing the issue happen in Edge as well. The frontend is receiving a new JWT when

/session/refresh

is called, and also

/user/email/verify

. I'm not sure why the verify route is being called.

There are two mergeIntoAccessToken payload functions. One on the session object that’s a result of session verification. This has an effect on the current session on the frontend immediately. And one of the sessionHandle, which you are using. This has an effect on the session tokens on the frontend when they refresh.

The email that you signed in with, is that unverified?

It's marked as verified in the dashboard

I see. So if you login again, it should not call the email verify API every time on page reload. Is that API still being called?

I don't believe I have anything set up to do that locally, but 304 is often returned from repeat api calls. After using ctrl+f5 for a full refresh in the browser it stopped giving me multiple JWTs.

You might wanna see what is resulting in 304

I don't know what configuration would cause it to cache other than the default express settings

You might be using some middleware in express. Maybe add that middleware after our middleware

That would make sense, I'll see if I can find what's causing it

Yup. Once you solve this issue, I think things should work as expected.

Well... Caching definitely seems like the cause. Quick test with

app.disable('etag');

seems to be working as intended.

Right ! So this has happened in the past with other users. For them, the 304 were coming cause they were using the react proxy feature to load the react app on a different port than the web server (which was also the same as the api server)

Thanks again, will keep that in mind too

👍