> ## Documentation Index
> Fetch the complete documentation index at: https://www.dynamic.xyz/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# IndexedDB is unavailable or closing

> Why browser storage for session keys goes away, what the SDK does about it, and what your app should do when it stays unavailable

```
InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing.
```

On the web, Dynamic keeps each user's session signing key and device signing key in the browser's IndexedDB. Those keys are generated so that no code can read the private material, only ask the browser to sign with them, and IndexedDB is the only web storage that can hold a key like that. Sign-in and wallet verification need them, so they fail when IndexedDB is unreachable.

## What causes this

* **Memory pressure.** The browser closes open IndexedDB connections to reclaim memory. Mobile Safari does this most aggressively, so a user with many tabs open on an older iPhone hits it first.
* **Private browsing and storage restrictions.** Some browsers block IndexedDB entirely in private windows, or when the user has blocked site data.

In both cases the key itself is intact. Only access to it is blocked.

## What the SDK does

* Reconnects and retries a read, backing off between attempts, for up to 3 seconds before it reports the storage unavailable.
* Queues every write and retries it with backoff, so a key created while storage is down is still written once the browser recovers.
* Keeps a record of deleted keys, so a key the SDK reports as deleted cannot come back after the browser recovers.

Storage that recovers within that budget is invisible to your app.

## What your app should do

When storage stays unavailable past the SDK's own retries, the SDK reports the failure rather than treating the key as missing, so your app can decide. It raises a distinct error for each case: one for storage that is unreachable right now, and one for a key that is genuinely gone. Handle them differently. For unreachable storage, give the user two options: retry in a moment, and sign in again if they prefer not to wait. For a missing key, sign the user out and let them sign in again, which creates a fresh key. A browser that blocks IndexedDB outright cannot hold a key at all, so a user in a private window or with site data blocked has to leave that mode before either path works.

Your SDK's session management guide covers the error names and the code to handle both cases.

<Note>
  Native mobile apps are not affected. On iOS and Android the SDK stores these keys in the platform keychain, not in IndexedDB.
</Note>