Skip to content

NavigatorLockAcquireTimeoutError on client init — no way to silence lock acquisition #1517

@ozzman02

Description

@ozzman02

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

When initializing a Supabase client in an Angular 18 standalone app, a NavigatorLockAcquireTimeoutError consistently appears during startup — even though navigator.locks is not used anywhere in the application.

The error originates from Supabase’s internal auth module, and there’s no documented way to silence or defer this behavior.


To Reproduce

  1. Create a Supabase client with:
createClient(SUPABASE_URL, SUPABASE_KEY, {
  auth: {
    persistSession: false,
    storage: localStorage,
    autoRefreshToken: true,
  },
});
  1. Wrap client creation in requestIdleCallback to defer execution:
requestIdleCallback(() => {
  supabase = createClient(...);
});
  1. Run the app and observe the browser console

  2. See error:

NavigatorLockAcquireTimeoutError: Acquiring an exclusive Navigator LockManager lock "lock:sb-xxxx-auth-token" immediately failed

Expected behavior

  • No lock error unless navigator.locks is explicitly used
  • Supabase should expose a way to disable or defer lock acquisition
  • Development console should remain clean unless session persistence is actively used

Screenshots

[Supabase Init] Cliente creado (idle)
NavigatorLockAcquireTimeoutError: Acquiring an exclusive Navigator LockManager lock "lock:sb-xxxx-auth-token" immediately failed
[AuthStateChange] INITIAL_SESSION
[Session Vacía o inválida]

System information

  • OS: Windows 11
  • Browser: Chrome 126
  • Version of supabase-js: 2.52.0
  • Version of Node.js: 20.x
  • Angular version: 18.2.0 (standalone)
  • Zone.js: 0.14.10

Additional context

The error does not break functionality — session detection works, auth state changes fire, and user login proceeds correctly.

However, the console warning affects QA pipelines and environments with strict startup logging rules.

Proposed fix: allow disabling this lock logic via config, e.g.:

auth: {
  ignoreLockErrors: true
}

Or expose a way to manually control or override the default navigator.locks usage.

Happy to help validate or test if needed — thanks for all your work!

Metadata

Metadata

Assignees

Labels

bugSomething isn't working

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions