User Forced to Go Through Login Flow Twice After Session Expired

[tyler-dane]

Prerequisites

• Using an up-to-date main branch

Expected Behavior

1. User tries to access Compass after an extended time (after their session expired)
2. User redirected to login screen
3. User presses login button, prompting Oauth dialog
4. User confirms Oauth dialog
5. User's sync is initialized
6. Compass redirects to home page
7. User can access and edit events like normal

Current Behavior

1-6: same
7: Compass redirects to home page, which triggers requests for /api/event....
8. The request fail with 401 unauthorized from SuperTokens
9. User is redirect to login page
10. User clicks through sign in button and dialog AGAIN
11. User is redirected to home page
12. User can finally access and edit events like normal

Steps to Reproduce

Here are the logs that accompany the above scenario:

# tries to access events, 401 correctly return (session expired)
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 154.687ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 148.039ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 1.188ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 1.079ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 1.112ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.927ms Sat, 09 Mar 2024 21:01:24 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.744ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.681ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.708ms Sat, 09 Mar 2024 21:01:25 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.650ms Sat, 09 Mar 2024 21:01:25 GMT

# after going through oauth dialog box
68|backend  | 24-03-09 21:01:41 [debug] app:sync.helpers: REMINDER: Channel will expire in 7200 minutes (5 days)
68|backend  | 24-03-09 21:01:41 [warn] app:user.service: Re-syncing google data for user: 651488733aa260d5183921c1
68|backend  | 24-03-09 21:01:41 [debug] app:sync.service: Stopping all gcal event watches for user: 651488733aa260d5183921c1
68|backend  | 24-03-09 21:01:41 [debug] app:sync.service: Skipped stop for calendarId: test1@gmail.com due to missing field(s):
68|backend  |             channelId: undefined
68|backend  |             resourceid: eRqPWi.....
68|backend  | 24-03-09 21:01:42 [debug] app:sync.helpers: REMINDER: Channel will expire in 7200 minutes (5 days)
68|backend  | 24-03-09 21:01:42 [info] app:sync.service: Sync initialized for channelId: a4c00712-85d1-......
68|backend  | 200 POST /api/sync/gcal/notifications 0.829ms Sat, 09 Mar 2024 21:01:42 GMT
68|backend  | 200 POST /api/oauth/google 1814.245ms Sat, 09 Mar 2024 21:01:43 GMT

# but the next request still fails with the same 401 error (why???)
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.862ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.620ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.634ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.584ms Sat, 09 Mar 2024 21:01:43 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.683ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 0.781ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.587ms Sat, 09 Mar 2024 21:02:10 GMT
68|backend  | 401 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 0.600ms Sat, 09 Mar 2024 21:02:10 GMT

# creating an event in Google Calendar is triggered (ie, the sync is setup correctly)
68|backend  | 24-03-09 21:02:24 [debug] app:sync.service.helpers: updating: "synced?"  | eRq......
68|backend  | 200 POST /api/sync/gcal/notifications 248.032ms Sat, 09 Mar 2024 21:02:24 GMT

# user goes through Oauth again
68|backend  | 200 POST /api/oauth/google 743.598ms Sat, 09 Mar 2024 21:07:03 GMT

# now it works
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 111.797ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 42.320ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 36.655ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 33.446ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?start=2024-03-03T00:00:00-06:00&end=2024-03-09T23:59:59-06:00 16.417ms Sat, 09 Mar 2024 21:07:03 GMT
68|backend  | 200 GET /api/event?someday=true&start=2024-03-01&end=2024-03-31 12.486ms Sat, 09 Mar 2024 21:07:03 GMT

Possible Solution (Not obligatory)

• It seems like Supertokens isn't creating a new session the first time. Perhaps we need to call their API differently when signing in for the first time.

Context

This affects users by giving them the impression that the sign in is broken (it kinda is), which causes them to give up before trying again a second time.