Incorrect redirect after page refresh on protected route when devMode is false (State potentially lost)

[Rohithzr]

When using authkit-react with devMode={false}, refreshing the browser on a protected route (e.g., /convo/some-id) causes an incorrect redirection flow. Instead of returning the user to the original protected route (/convo/some-id) after authentication, the user is ultimately redirected to /login and then often to the root (/). This behaviour does not occur when devMode={true}.

The issue seems related to the handling of the state parameter passed to signIn and retrieved in the onRedirectCallback. Debugging suggests the initial state correctly contains the returnTo path, but after the redirect back from WorkOS to the redirectUri (/login in this case), the state available to onRedirectCallback or subsequent logic appears incorrect or lost, preventing the intended redirect back to the original protected route.

Steps to Reproduce

1. Configure AuthKitProvider with a valid clientId, redirectUri (e.g., /login), and crucially, devMode={false}.
2. Implement a mechanism to protect routes, such as the useUser hook provided below, which calls signIn if the user is not authenticated.
3. Set up a login page (/login) that handles the redirect from WorkOS (using signIn({ context }) if necessary) and redirects logged-in users away (e.g., to /).
4. Log in to the application successfully.
5. Navigate to a protected route that is not the root path (e.g., /convo/some-id).
6. Refresh the browser page (F5 / Cmd+R).
7. Observe the redirection flow.

Expected behavior

After refreshing the page on /convo/some-id:

1. The useUser hook detects no user initially and calls signIn({ state: { returnTo: '/convo/some-id' } }).
2. The user is redirected to the WorkOS Hosted UI (may happen instantaneously if already authenticated with WorkOS).
3. WorkOS redirects the user back to the redirectUri (/login in this case) with an authorization code and the original state.
4. AuthKitProvider processes the redirect.
5. The onRedirectCallback is invoked with the original state, containing { returnTo: '/convo/some-id' }.
6. The callback navigates the user to /convo/some-id.

Actual behavior

After refreshing the page on /convo/some-id:

1. The useUser hook detects no user and calls signIn({ state: { returnTo: '/convo/some-id' } }). (Confirmed via logs)
2. User is redirected to WorkOS and back to /login?code=....
3. AuthKitProvider processes the redirect.
4. The onRedirectCallback either doesn't receive the correct state or subsequent logic interferes. Debugging suggests the state retrieved at this point might be incorrect (e.g., potentially reflecting /login instead of the original returnTo).
5. The logic in the /login page might then execute (e.g., the if (user) check) because the intended redirect didn't happen immediately or correctly, causing a final redirect to /.

CC @nicknisi

[nicknisi]

Hi @Rohithzr can you clarify how the redirect is occurring? I tried reproducing in this example app (branch: nicknisi/devmode-false) and it seems to be correctly redirecting back to /account for me. Would you mind giving it a try and seeing if there's a way to get this to reproduce? Thanks!

[Rohithzr]

@nicknisi The example app is helpful, even I tried reproducing it but i am unable to and doing more digging I see that for me this happens only on the dynamic routes /chat/:id for me which is odd. I am trying to debug the issue and will update, it might not be a workos issue.