Using useRevalidator's revalidate function and destroyed sessions

[brandonpittman]

I've got a problem where a user might logout in one tab, but another tab might have the app in a still logged in state. I'm using cookie sessions so when they log out, the session cookie disappears. If I trigger a revalidate in the other tab on visibilitychange, the page doesn't realize the session's gone, but if I call revalidate a second time, the app seems to realize the session's gone and it triggers the redirect to the login page.

I'm getting this to behave how I want it to by calling revalidate twice, but it means the first one gets canceled, and this feels sloppy. Can anyone tell me why calling it twice makes it work the way I want it to and/or why calling revalidate once doesn't?

[sergiodxa]

Are you using createCookieSessionStorage? I think what's probably happening is that the first revalidate sent the Cookie, because it's still there, and the second one doesn't send it anymore because.

So it's most likely a browser issue. With another session storage it wouldn't be an issue because the session data on your storage (e.g. the DB) will not exists anymore.

Have you tried using Broadcast Channel API instead? This way, when the user finish the logout on one tab it will send a message to other tabs and trigger a revalidation, instead of waiting for the user to switch to the tab, risking a race condition between the logout and the revalidation.

[brandonpittman]

Broadcast Channel solved my issue. Thank you, @sergiodxa!