User is required to re-auth frequently | 401 response from `/api/auth/google`

[tyler-dane]

Where did this happen?

Hosted (app.compasscalendar.com)

Expected Behavior

When going to Compass, the user shouldn't have to reauthenticate with Google oauth on a daily basis

Current Behavior

When going to Compass, the user is required to go through the full login flow on a daily basis

Steps to Reproduce

1. Open devtools
2. Go to Compass
3. Wait a day
4. Go to Compass again
5. Look at /refresh call: https://app.compasscalendar.com/api/session/refresh and see it responds with 401 and the below payload
6. Look at /api/auth/google call and see that it also returns 401
7. You'll be redirected to the login page after the backend returns the 401 response

401 payload:

{message: "unauthorised"}

Backend logs:

0|backend  | 401 GET /api/auth/google 0.443ms Thu, 23 Oct 2025 01:01:02 GMT

[/+][-]

Possible Solution

What is the cause of the refresh token failing?

Context

This is a very negative experience that will cause even the most supportive users to give up.

[victor-enogwe]

See #1154 for sync maintenance fixes

[tyler-dane]

This is still happening after #1154 was merged: I was just forced to re-auth after just a few hours.

[tyler-dane]

The auth token refresh are no longer dependent on the sync process.
It used to be dependent - when the watch schema was embedded in thecanDoIncrementalSync method for auth capability check.

This leaves SuperTokens as the reason for the expiration.

I've attached a local screenshot of SuperToken's refresh working locally, after I refreshed the sync(has no effect on the auth) and the SuperTokens token refresh happened.

I haven't been able to reproduce this in staging.

I reproduced in production and I've attached a screenshot of the internal /refresh endpoint by super tokens failing.

Actions:

• Check for sudden signouts on the email above between today and tomorrow - note exact conditions where this happens for further debugging
• Update the SuperToken core to v11.1 and restart the corresponding production/staging app. Ensure all config is set as expected.

---

I just updated ST core to 11.1 and restarted prd/staging

Got a successful /refresh call. Hoping that's all, but will keep monitoring for a bit before closing this.

EDIT: Still happening, as confirmed by me and another user. Details added to above.

[victor-enogwe]

We do not currenly control how /session/refresh works(we rely entirely on the supertokens-node library implementation).

To address this, the next step will be to look at upgrading the supertokens-node library.

We are currently running supertokens-node v20.1.7

I'll review the changes between v20.1.7 and v23.0.1: supertokens/supertokens-node@v20.1.7...23.0
to see if any of those changes may be the reason why /session/refresh fails.

Once done, I'll send an update on what course of action we'll need to take @tyler-dane

[victor-enogwe]

We also need to look at what the duration of the gRefresh token supertoken makes for us looks like on login or signup. We might be getting a short-lived refresh token, which expires before supertokens can refresh the session(when the user becomes active again). In which case we need to get supertoken to generate tokens with the expected longer expiry.

[victor-enogwe]

Important links

supertokens/supertokens-node#1009
supertokens/supertokens-node#1007

These supertokens changes should mitigate issues related with having unrelated cookies in the session cookie(eg. posthog) during refresh

TODO - Backend

• Add logging to the refresh flow according to - https://supertokens.com/docs/post-authentication/session-management/advanced-workflows/customize-error-handling
• Prevent the websocket server's session verification from triggering the refresh endpoint.
• Update the supertokens-node package to the latest stable version
• change the the refresh token validity lifetime from 144000 seconds(1.6 days) to about 489600 seconds(5.6) days
• Watch the logs for refresh issues