[Auth] GoTrueClient uses infinite timeouts for lock acquisition causing deadlocks in production

[dtinth]

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

I encountered a situation where Supabase Auth never finish initializing.

• The impact on my app is that it never finishes initializing and any auth operation hangs.

• I already checked that onAuthStateChange is not async and doesn't call any Supabase API, so #762 doesn't apply.

• The GoTrueClient initialization hangs indefinitely on some devices (in my case, Chrome Android) due to a lack of timeouts in the Web Locks API implementation.

• I investigated this by digging into the source code and enabling the undocumented debug option. On the affected device, the #_acquireLock call never resolved

  On a working device, the debug log is normal	On a problematic device, it got stuck at #_acquireLock

  Additionally, on a problematic device, checking supabase.auth.initializePromise returns a never-resolving promise.

• It seems that a previous lock wasn't properly released… when I run await navigator.locks.query() I see that some locks are being held indefinitely.

  Held locks

• Is it really a good idea to wait for a lock indefinitely?? Sorry if I sound frustrated, but I kinda am – I just paid for Supabase Pro and didn't expect this from a professional auth solution. I kinda spent an hour scratching my head figuring out what's wrong with my app. That said, I really appreciate the overall quality of Supabase and believe this is just an edge case to be fixed. I hope this investgation will be useful.

To Reproduce

This issue is not easily reproducible as it appears to be race condition or environment-dependent. However, it occurs in production on real devices where users experience complete authentication failure.

The fundamental issue is that the current implementation holds Web Locks indefinitely without a timeout, which violates basic concurrency principles. Any scenario that prevents proper lock cleanup can trigger this deadlock.

Expected behavior

Supabase Auth should be able to recover from a situation where the lock is not properly released. The lock mechanism should have a timeout and fallback to ensure the client doesn't hang indefinitely.

Currently, the there is no acquireTimeout (-1 means no timeout):

https://github.com/supabase/auth-js/blob/aadf02e63179746a06451f4247a370dfd05740ea/src/GoTrueClient.ts#L358-L362

Maybe it should be set to some sane value, like maybe 1 minute.

Screenshots

The app doesn't launch as Auth never finished initializing, and User sees a white page.

System information

• OS: Android
• Browser: Chrome
• Version of supabase-js: 2.71.1
• Affected code: @supabase/auth-js GoTrueClient

Additional context

Current workaround

Until a proper lease is implemented, I am currently working around this issue by specifying a noOpLock when initializing Supabase. However I don’t know what might go wrong if we skip the locks.

const noOpLock = async (name: string, acquireTimeout: number, fn: () => Promise<any>) => {
  return await fn()
}

const supabase = createClient(url, key, {
  auth: { lock: noOpLock }
})

Debug session and debug log

Checking the locks in JS Console

await navigator.locks.query()

{
  held: [
    {clientId: '0ccb43ce-27c2-423e-8cbe-63a9c2da37b4', mode: 'exclusive', name: 'lock:sb-nmzhiwafofgwvqucnbds-auth-token'}
  ],
  pending: [
    {clientId: '0ccb43ce-27c2-423e-8cbe-63a9c2da37b4', mode: 'exclusive', name: 'lock:sb-nmzhiwafofgwvqucnbds-auth-token'},
    {clientId: 'e6ee664e-e2d9-4f1d-8a9a-0ab0b5e83ee6', mode: 'exclusive', name: 'lock:sb-nmzhiwafofgwvqucnbds-auth-token'},
    {clientId: 'e6ee664e-e2d9-4f1d-8a9a-0ab0b5e83ee6', mode: 'exclusive', name: 'lock:sb-nmzhiwafofgwvqucnbds-auth-token'},
    {clientId: '9d09c2ce-ac43-4783-b356-e988cae6bc26', mode: 'exclusive', name: 'lock:sb-nmzhiwafofgwvqucnbds-auth-token'}
  ]
}

Debug logs showing the hang:

GoTrueClient@0 (2.71.1) 2025-09-13T19:24:55.355Z #_acquireLock begin -1
GoTrueClient@0 (2.71.1) 2025-09-13T19:24:55.355Z #onAuthStateChange() registered callback with id a5571c4b-9f69-4111-b314-119f2e0ecb87
(hangs here - never proceeds to lock acquisition)

[APTy]

Thanks for creating this. I ran into this and am using the same noOpLock workaround. I noticed another thread with many others having the issue. I'm surprised this bug has been around for so long, but maybe it's hard to reproduce. This is a big problem they should be taking very seriously and fix ASAP.

EDIT: I should mention, this issue only intermittently showed up in my next.js app when running npm run dev, but always showed up when doing npm run build && npm start

[coolcorexix]

you saved my 2 hour vibe code session. how can this be hard to reproduce, I was 1 prompt generating the auth and this happen right away

[kaimckinnon]

I've been banging my head against this bug for a day. Thanks for reporting it and coming up with a temporary workaround. Have you experienced any issues with skipping locks? That seems potentially quite bad, and I don't have a good sense for what the repercussions could be.

[dtinth]

Have you experienced any issues with skipping locks?

@kaimckinnon I have been using this workaround for ~3 weeks now (starting from issue creation) and have never encountered any issues yet, nor did any user report any issue related to auth.

I don't have a good sense for what the repercussions could be

I have no idea too 😅 but if I have to guess:

• Without locks, different open tabs may try to refresh tokens at the same time, possibly leading to multiple redundant requests being made to the auth server.
• Without locks, race conditions may corrupt the local state, which might lead to user getting logged out due to invalid token. (I kinda assume that corrupt local state would result in session invalidation (which is recoverable; user just needs to relogin), and not a crash 🤞).

I think that in both cases the outcome is more favorable to the auth system stop working completely, so I opted to implement the workaround in my app.

[jlemonz]

Hi,
I am also experiencing a weird condition. Only happening on android chrome. I use nuxt supabase module. And it looks like when u return to the app after doing other stuff supabase freezes and won't do anything anymore. Sign out doesn't work. Redirect to login page if no user not. No fetching data etc. The weird thing is that everything works fine on other devices. And no errors are thrown in. Can this also be this issue? Or does this only happen when you try to login?

[dtinth]

@jlemonz Android Chrome is where I initially noticed this issue too. However, I did not use Nuxt Supabase module, just plain Supabase JS SDK.

[KariNarhi28]

I am not sure if this is related, but I just had a situation where I messed something up with db reset / migration changes and even after reverting the file-changes and doing a reset with the working migration files and restarting both supabase and my app, I couldn't get the auth session changes and my Angular route guards blocked me from opening any pages, no matter if I was supposed to be logged in or out.

So I was like soft-locked out of my own system.

I managed to recover by sending myself a magic link, logged in through it and got new session which fixed everything.

After this everything was fine, though in the db there still were remnants of the old session so I logged out and logged back in to clear the old sessions since Supabase deletes them on log out.

[GuyRubi]

I figured out why it was happening to me, although the cause may be different from OP because his workaround didn't solve it.

My issue was that initializePromise never returned.

In my case I created an infinite loop by having a listener on authChange which itself will calls auth.getSession().

This happens because the _initialize() function calls _notifyAllSubscribers before returning, thus it never returns the promise.
In my case the flow was _initialize() -> _recoverAndRefresh() -> this._notifyAllSubscribers('SIGNED_IN', currentSession);

To be fair, the docs mention this can happen pretty explicitly https://supabase.com/docs/reference/javascript/auth-onauthstatechange

[dtinth]

Thanks for information about this issue. I hope it can be properly solved eventually.

I looked at my usage of onAuthStateChange — there's no usage of “other Supabase functions” in here:

    // Listen for auth changes
    supabase.auth.onAuthStateChange((event, newSession) => {
      session.value = newSession
      user.value = newSession?.user ?? null
      loading.value = false
    })

So yeah, this might be a separate issue.

---

What boggles my mind about this issue:

• If there is a deadlock, I kinda expect that it wouldn't persist — a browser refresh should fix the issue. For this issue, the deadlock is persistent. Have to quit the browser or manually intervene.

• Even if there a persistent deadlock, I kinda expect there be some kind of timeouts so at least there's a time limit to this locking issue. For this issue, the lock is held indefinitely, with no way to self-heal from this situation. From experience I never found a case where locks without timeouts make sense… Why not use a lease?

• I’ve used many auth solutions. Why is Supabase Auth the only one with this deadlocking footgun?

[leopsidom]

+1 encountered exact same issue for android chrome.