Auth hydrates null after IndexedDB Auth record is present before pagehide but missing on next reload

[boraberkcetintas]

Operating System

User reports include Chrome on both macOS and Windows. The strongest trace below is from Chrome on macOS.

Environment (if applicable)

• Browser web app
• Chrome 148/149 observed
• React app / Next.js app
• Firebase Web SDK modular API
• Auth persistence: default browser local persistence via getAuth(app), which stores the Auth user in IndexedDB when available

Firebase SDK Version

The clearest local/production evidence I currently have is on:

• firebase@12.14.0
• @firebase/auth@1.13.2

Similar user-facing sign-out reports existed on earlier 12.x builds, but the evidence below is from 12.14.0.

Firebase SDK Product(s)

Auth

Project Tooling

• Next.js / React browser app
• Firebase Auth custom-token sign-in flow

Detailed Problem Description

I am investigating intermittent forced sign-outs in browser apps using the same Firebase project. Users report that they can be actively signed in, leave the tab open or switch away, then return and find themselves back on the sign-in screen.

This does not appear isolated to a single application surface. In one internal reproduction, I noticed that one internal dashboard had signed out, then checked other already-open tabs in the same Chrome profile. Two other internal apps and the production app were also signed out around the same time. The affected tabs included both production-hosted and local-development origins using the same Firebase project. I understand that different origins do not share the same IndexedDB store, so I am not claiming a shared IndexedDB record. I do not know yet whether this points to shared Firebase Auth/backend state, browser/profile-level storage behavior, or multiple per-origin Auth instances independently reaching null state around the same time. I am only including it because the multi-app/same-time shape seems important.

I initially suspected ID token refresh or TOKEN_EXPIRED, but a recently captured trace does not support that as the cause for this case. The stronger signal is that the Firebase Auth IndexedDB persisted user record was present before pagehide/beforeunload and missing on the next page load.

Sanitized trace from one affected browser session on one local-development origin:

2026-06-08T12:33:32Z
  onIdTokenChanged: user
  authStateReady: user
  Firebase Auth IndexedDB database: present
  Auth object store: present
  current app Auth record: present
  persisted record includes uid-like value: yes
  persisted record includes refresh-token-like value: yes
  persisted record includes access-token-like value: yes
  persisted access token expiration: 2026-06-08T12:58:25Z
  navigation type: reload
  document.wasDiscarded: false

2026-06-08T12:37:56Z
  beforeunload
  pagehide

2026-06-08T12:40:31Z
  new page load / reload
  Firebase Auth IndexedDB database: present
  Auth object store: present
  current app Auth record: missing
  auth record count: 0
  object store key count: 0
  authStateReady: null
  onAuthStateChanged: null
  onIdTokenChanged: null

The important detail is that, on the reload where Auth becomes null, IndexedDB itself is available and the Firebase Auth database/store still exists. The current-app persisted Auth user record is already gone before my app sees authStateReady() resolve.

I checked Firebase/Google Cloud Identity Toolkit request logs for the same anonymized user and the same UTC window:

• The same user had successful GetAccountInfo calls around 2026-06-08T12:33:32Z.
• The token in those successful requests had exp = 2026-06-08T12:58:25Z.
• I did not find TOKEN_EXPIRED, INVALID_ID_TOKEN, USER_NOT_FOUND, or a Secure Token error tied to this user/window.
• I also checked the affected user's Auth metadata; the user was not disabled, and the token-valid-after / revoke timestamp was not close to this event.
• General Identity Toolkit errors in that window were unrelated sign-in/OTP errors for other users.

So in this case I do not think the sequence is:

/v1/token returns TOKEN_EXPIRED -> SDK signs out -> IndexedDB record is removed

The observed sequence in this captured case is:

Auth record exists -> pagehide/beforeunload -> Auth record is missing on next reload -> SDK hydrates null user

I did not capture the exact moment when the IndexedDB auth record disappeared. Because of that, I cannot prove whether the SDK removed the record before the reload, or whether the SDK simply observed an already-missing record during initialization.

The SDK code path I am trying to understand is the IndexedDB local persistence synchronization path. As far as I can tell from the bundled SDK code, IndexedDB local persistence polls the object store and notifies listeners with null when a key exists in its local cache but is not returned by getAll(). Auth then handles that persistence change by reading the current user from persistence and updating Auth state. I am not claiming that this polling path is the proven cause; I am including it because it is the closest SDK path I found that can propagate a missing persisted Auth key into null Auth state. This looks related in shape to #9471, although that issue is about browserLocalPersistence and fallbackToPolling, while this case uses IndexedDB persistence.

Expected Behavior

If a valid persisted Auth user exists in IndexedDB before pagehide, and there is no known token revoke, account disable/delete, explicit sign-out, or token backend error, the SDK should continue to hydrate the same current user after reload.

A transient IndexedDB read or synchronization anomaly, if one can occur, should not permanently convert the user into a signed-out state without confirming that the user was intentionally signed out or invalidated.

Actual Behavior

The browser returns to the app after pagehide/reload and Firebase Auth hydrates as signed out:

authStateReady(): currentUser === null
onAuthStateChanged: null
onIdTokenChanged: null

At that moment, app diagnostics show that the Firebase Auth IndexedDB database and object store still exist, but the persisted Auth user record is missing.

Steps and code to reproduce issue

I do not yet have a deterministic reproduction. This is intermittent and production/local-session observed.

Observed rough conditions:

1. Sign in with custom token.
2. Auth state is active and the Firebase Auth IndexedDB persisted user record exists.
3. Leave the tab open or switch away.
4. Browser emits pagehide/beforeunload.
5. Return/reload a few minutes later.
6. The Firebase Auth IndexedDB database/store still exists, but the Auth user record is gone.
7. Auth hydrates as null and the app routes to sign-in.

Related Issues

• Unexpected sign out when using local storage persistence and fallbackToPolling = true #9471 looks related in shape: unexpected onIdTokenChanged(null) apparently connected to a polling path, but that report is for browserLocalPersistence / localStorage fallback polling.

Question

Is there a known IndexedDB local persistence path in Firebase Auth that can remove the authUser key, or propagate a missing authUser key into null Auth state, during pagehide/reload? In this captured case I did not find evidence of an explicit signOut(), token revoke near the event, account disable/delete, or token backend error.

I can provide additional sanitized diagnostics or test a debug build if there is a specific internal field/stack that would help identify where the persisted Auth record disappears.

[DellaBitta]

Hi @boraberkcetintas,

Thank you for the highly detailed issue report! I will notify the Auth team of this issue and have them look at it.

In the meantime, for a quick test could you run your code with browserLocalPersistence? This wouldn't be for a work around, as you might run into #9471, but it would help us isolate the timing and code flow that's causing the issue.

Note: I see the similarities to #9471, but because this explicitly involves IndexedDB and pagehide lifecycle events, we should track this async storage path separately