Supabase operations in onAuthStateChange will cause the next call to supabase anywhere else in the code to not return.

[izhan]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

await supabase.auth.getSession() will hang indefinitely every hour or so, until the user reloads the page. We suspect it's related to the token needing to be refreshed.

To Reproduce

1. Sign into an application with Supabase auth running
2. Wait an hour (or however long it takes for your token to expire)
3. Reload the page and call await supabase.auth.getSession()
4. getSession will hang indefinitely

It's unclear right now whether (4) happens all the time or only some of the time. But we've been managing to reproduce pretty frequently, both locally and in prod. It's been affecting our customers as well.

Reloading the browser after (4) will immediately resolve the issue. Subsequent reloads will be fine, until an hour of inactivity in which this problem occurs again.

We've tried multiple versions of supabase-js and gotrue already, to no effect. This has been occurring for the past few weeks.

supabase/supabase#15930 seems related but that ticket seems to be concerned with immediately after Google OAuth. Our problem occurs well after initial login.

Expected behavior

We expect getSession to never hang indefinitely

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: [e.g. macOS, Windows] macOS
• Browser (if applies) [e.g. chrome, safari] Chrome
• Version of supabase-js: [e.g. 6.0.2] Multiple (2.24, 2.26, 2.31)
• Version of Node.js: [e.g. 10.10.0] v18.16.0

Additional context

We tried this on multiple versions of supabase-js (2.24, 2.26, 2.31) and gotrue (2.42, 2.43.1, 2.46.1)

[j4w8n]

If you lower your jwt expiry time, does that also shorten the timeframe of how often this occurs?

[hf]

@izhan What "environment" is your code running in -- what browser (did you try others?), what framework, what TypeScript targets...?

We generally expect to see issues reproduced with the latest version of gotrue-js before we can continue, as some of the versions you listed are known to have issues.

[izhan]

If you lower your jwt expiry time, does that also shorten the timeframe of how often this occurs?

Have not tried yet, can do that

@izhan What "environment" is your code running in -- what browser (did you try others?), what framework, what TypeScript targets...?

We generally expect to see issues reproduced with the latest version of gotrue-js before we can continue, as some of the versions you listed are known to have issues.

Repro'd on Chrome, Safari, Firefox. Framework is ReactJS. TS target is ES2020.

We've tested on supabase-js@2.31 and gotrue-js@2.46.1 which I believe were latest. The other versions I listed were tested after following threads in #768 and supabase/supabase#15930 – all of which didn't work.

New data point: we've recently downgraded back to supabase-js@2.2.2 - the oldest known version that worked for us - and getSession() no longer hangs. We're gonna try this version for a few more days and monitor our logs to see if it hangs for any of our customers.

[aviadmini]

@izhan did the version downgrade work?

I most likely am facing the same issue in one of the edge cases:
when app tries to load and if Supabase backend is unreachable (e.g. local dev setup is down) then calling await supabase.auth.getSession() hangs. It's pretty bad in my case because I'm using Svelte auth helpers and it blocks +layout.ts which blocks the rest of the app from loading.
Should I open a separate issue?

[izhan]

@aviadmini the downgrade did work for me. Similar hang here too with the newer version, but I don't see any failed network requests, do you? It seemed to be a bug in the gotrue logic, ie when to actually kickoff the call to backend

[aviadmini]

When supabase is unreachable (e.g. local dev setup is down) there are console errors for the unsuccessful fetch and retries during a call to svelte auth helpers functions. Right after that the following call to await supabase.auth.getSession() never completes

[danrasmuson]

We experienced this issue...

Our call supabaseClientSide.auth.getSession().then(({ data: { session } }) => session); would just hang forever under certain circumstances when the client did not have the token.

The way our team was able to resolve this was by upgrading from

"@supabase/supabase-js": "^2.26.0"

to...

"@supabase/supabase-js": "^2.33.1"

[felix-andreas]

We are also experiencing as similar issue when updating from supabase-js 2.30 -> 2.31. the only change between these versions seems to be supabase/supabase-js@c07ce23 which updates "@supabase/gotrue-js from 2.43.1 to 2.46.1

More specifically it happens, when awaiting a supabase function within the onAuthStateChange. The callback hangs indefinitely, depending on how fast the Promises returns. For us it only happens if the supabase-js client points to a local SUPABASE_URL setup, but not with a remote SUPABASE_URL...

[kjhughes]

I also experienced getSession()'s returned promise never resolving. In my case, with @GaryAustin1 's help on Discord, I found that in my initial, rough onAuthStateChange() handler, hitting the database for all auth events indiscriminately was causing the problem. Specifically, hitting the database when receiving TOKEN_REFRESHED callbacks broke something such that subsequent getSession() calls would all hang.

I will of course refine the problematic onAuthStateChange() handler, but it would be great if getSession() could be fixed to return an error or throw an exception rather than return a promise that never resolves for this and any related problems.

supabase-js version 2.36.0
gotrue-js version 2.54.0

[kangmingtay]

hey everyone, i'm trying to reproduce this so that i can figure out why it happens but i need some help here -

@andreasfelix you mentioned that:

when awaiting a supabase function within the onAuthStateChange. The callback hangs indefinitely, depending on how fast the Promises returns. For us it only happens if the supabase-js client points to a local SUPABASE_URL setup, but not with a remote SUPABASE_URL...

which function are you calling in onAuthStateChange that leads to this?

@kjhughes just wondering, why do you need to call getSession() inside of the callback for onAuthStateChange()? The onAuthStateChange() method will pass the event and the session as parameters to the callback function so there shouldn't be a need to call getSession() again

[kjhughes]

@kangmingtay: Thanks for investigating.

You are right: Calling getSession() within the onAuthStateChange() callback was an unnecessary mistake.

However, removing that call did not itself resolve the issue where another getSession() call would never return. I also had to remove from the onAuthStateChange() callback the code whereby it accessed the database. Only then would the non-resolving getSession() promise resolve.

More details are available in the linked Discord chat. Note that I believe I also observed that the scenario I described above (where onAuthStateChange() callback accessing the database hosed subsequent calls to getSession()) also hosed some other different subsequent supabase calls -- signInWithPassword(), for example.

[felix-andreas]

which function are you calling in onAuthStateChange that leads to this?

if I recall correctly any async operation that involves the supabase client, e.g.

supabase.auth.onAuthStateChange(async (event, session) => {
  switch (event) {
    case "TOKEN_REFRESHED":
    case "SIGNED_IN":
        await supabase.rpc(...)
    ...
  }
})

Our current workaround is to set a reactive variable (svelte) and run the effect whenever it changes:

supabase.auth.onAuthStateChange((event, session) => {
  switch (event) {
    case "TOKEN_REFRESHED":
    case "SIGNED_IN":
      dirty.set(true)
    ...
  }
})

dirty.subscribe(async ($dirty) => {
  if ($dirty) {
    dirty.set(false)
    await supabase.rpc(...)
  }
})

We didn't bother to look into why this works. I assume this somehow changes the order the microtasks are executed in (I am not super familiar with JS ...).