Coming from #85252 (comment).

Onyx Storage Errors — Summary Report

Time span: 2026-03-02 to 2026-03-30 (~4 weeks)

Total Failed to save to storage entries: 3,364,645

Distinct error types: 52

Methodology

Seven log messages were analyzed from OnyxUtils.retryOperation and OnyxUtils.reportStorageQuota in react-native-onyx:

Cross-referencing: auxiliary events were matched to the nearest Failed to save to storage entry sharing the same request_id within a 2-second window. This approach was validated by measuring time gaps between events: 99.5%+ of related events occur within 1 second of each other.

Platform inference: derived from the userAgent string in each log entry. Detection relies on unique tokens: Edge includes Edg/, Opera includes OPR/, Firefox includes Firefox/ (no Chrome/ token), and Chrome includes Chrome/ without Edge/Opera markers. These are checked in priority order to avoid misclassification (e.g. Edge's UA also contains Chrome/).

Storage Quota Check interpretation: on web, bytesUsed and bytesRemaining come from navigator.storage.estimate() which reports the browser's overall storage quota for the origin (not just the IndexedDB database). On native, bytesUsed is the SQLite database file size (via PRAGMA page_size * page_count) and bytesRemaining is the device's free disk space (via getFreeDiskStorage()).

Top 10 Errors

1. UnknownError: Internal error opening backing store for indexedDB.open. — 884,955 (26.3%)

• No eviction or quota check events — this is an IndexedDB internal failure unrelated to storage space
• This error is not classified as a storage capacity error in Onyx (STORAGE_ERRORS only includes QuotaExceededError for IDB), so it never triggers the eviction flow — it just retries immediately and fails repeatedly
• Likely caused by corrupted IndexedDB state, browser extensions interfering, or Chromium-level bugs

2. QuotaExceededError: The current transaction exceeded its quota limitations. — 865,703 (25.7%)

• 859,276 quota checks with mean 0.0% full — Firefox reports quota exceeded even when overall usage is negligible. The exact quota model (per-transaction, per-write, or other) is unclear from the data alone
• Firefox-exclusive error — different quota behavior from Chromium and Safari
• Eviction is triggered frequently, and relatively few requests end up exhausting retries (6,089), suggesting eviction generally helps resolve this error

3. UnknownError: Connection to Indexed Database server lost. — 637,821 (19.0%)

• Safari/WebKit-exclusive — the IDB connection drops unexpectedly
• No eviction or quota involvement — not recognized as a capacity error, so Onyx retries immediately without eviction
• 106K exhausted all retries (16.7% of this error) — immediate retries don't help because the connection itself is gone

4. QuotaExceededError: Encountered full disk while opening backing store for indexedDB.open. — 234,697 (7.0%)

• 0 at >= 95% and mean 0.0% full despite "full disk" in the error — this reflects IndexedDB's per-origin quota being exhausted, not the actual disk being full. The browser allocates a fraction of total storage to each origin, so "full disk" is a misnomer from Chromium
• Very few requests exhausted retries (6), suggesting eviction generally resolves the issue

5. InvalidStateError: Failed to execute 'transaction' on 'IDBDatabase': The database connection is closing. — 216,981 (6.4%)

• Cross-browser but Safari-dominant — the DB connection is being closed (page navigation, tab discard, or browser cleanup) while writes are in-flight
• Similar to #3: not a capacity error, so no eviction is triggered. Immediate retries are unlikely to help if the DB connection is closing

Issue was handled here: #84192

6. null — 90,661 (2.7%)

• The error object was null — no useful error message was provided by the storage backend
• Cross-browser, slightly Safari-leaning — may be a Safari-specific issue where the error object is not properly populated

7. NitroSQLiteError: database or disk is full — 89,174 (2.7%)

• 60,468 quota checks with mean 2.4% of device disk used — the SQLite database itself is relatively small compared to overall device storage, but the device's free space is exhausted by other apps/data
• Native-only (NitroSQLite) — very few requests exhausted retries (10), suggesting eviction generally resolves the issue

8. NitroSQLiteError: disk I/O error — 89,137 (2.6%)

• No eviction or quota events despite "disk I/O error" being explicitly listed in SQLITE_STORAGE_ERRORS. This is unexpected — the eviction path should be triggered but isn't. Needs investigation (see action items)
• disk I/O error is arguably not a storage capacity error and should probably be removed from SQLITE_STORAGE_ERRORS. It indicates filesystem corruption, SD card issues, or device under stress — evicting keys won't help with I/O failures
• Native-only

9. DataError: Failed to write blobs (InvalidBlob) — 63,281 (1.9%)

• Chromium-exclusive — blob data becoming invalid between when it's created and when it's written to IDB
• Notable that multiSetWithRetry dominates (76%) — batch writes are more susceptible
• Not a capacity error, so no eviction — retries are unlikely to help since the blob data is fundamentally invalid

10. QuotaExceededError (bare, no detail) — 51,900 (1.5%)

• The only error with significant >= 95% full cases (1,990) and the highest mean storage usage (4.2%)
• 1,196 failed to even get database size — navigator.storage.estimate() itself threw an error
• Chromium — generic quota exceeded with real storage pressure in some cases

Cross-Reference Summary

How many auxiliary events matched to a nearby Failed to save to storage (same request_id, within 2s):

Key Takeaways

Error Landscape

1. The top 3 errors account for 71% of all failures — and each is exclusive to a specific browser engine:

   • Chrome/Edge: Internal error opening backing store (26.3%)
   • Firefox: QuotaExceededError: transaction exceeded quota (25.7%)
   • Safari: Connection to Indexed Database server lost (19.0%)

2. Errors fall into two distinct categories with very different behaviors:

   • Quota/capacity errors (#2, #4, #7, #10 — ~36.9%): trigger eviction, and relatively few of these requests end up exhausting retries, suggesting eviction generally helps.
   • Connection/state errors (#1, #3, #5 — ~51.7%): do NOT trigger eviction, just retry immediately and often exhaust all retries. These represent data loss since the write is silently skipped.

3. 354K operations exhausted all 5 retries (10.5% of all errors), and retryOperation resolves with Promise.resolve() — the caller has no way of knowing data was lost.

Quota Check Insights

4. Storage usage is extremely low across all quota-exceeding errors. Mean usage never exceeds 4.2% even for genuine quota errors. This is because:

   • On web, navigator.storage.estimate() reports the browser's total origin quota (often tens of GB), and IndexedDB only uses a small fraction
   • On native, getFreeDiskStorage() reports total device free space, dwarfing the SQLite DB size
   • The actual per-origin storage limits enforced by browsers are much smaller than what estimate() reports as the total quota

5. Firefox's quota behavior is different from other browsers: it reports QuotaExceededError even when overall storage usage is at 0.0%. The exact quota model Firefox uses (per-transaction, per-write, per-database, or something else) is unclear from the data alone — but the pattern is 100% Firefox-exclusive and accounts for 25.7% of all errors.

6. Only 895 requests (0.027%) hit the "no evictable keys" dead end — it's rare for the eviction mechanism to run out of keys to remove.

Platform Distribution

7. Every major browser engine has its own dominant failure mode:

   • Chromium (Chrome/Edge): internal backing store errors, blob write failures
   • Gecko (Firefox): per-transaction quota limits
   • WebKit (Safari): connection drops and database state errors

8. Native (NitroSQLite) errors account for ~5.3% — split between disk full (which triggers eviction effectively) and I/O errors (which don't trigger eviction at all).

Action Items

1. Create GH issues to investigate each of the top 10 errors (except number 5) separately, where Sentry, VictoriaLogs and Fullstory could be used together to investigate some user scenarios with these errors to understand better why/when they happen, and look for a way to fix or lower this amount of errors.
2. Improve OnyxUtils.retryOperation and OnyxUtils.reportStorageQuota logging to always include the original error in the different possible logs we can have there, so it's easier to query and analyse them in Sentry/VictoriaLogs instead of having to check nearby logs in the same timestamp to discover what was the true storage error (that is logged here).
3. Remove disk I/O error and out of memory from SQLITE_STORAGE_ERRORS, as the data shows they never trigger eviction in practice (0 evictions, 0 quota checks out of 89K occurrences) and they shouldn't be related to "storage" errors anyway.
4. Explore retry backoff or different mechanism for connection errors in OnyxUtils.retryOperation. Errors #1, #3, #5 account for 51.7% of all failures. Currently retries are immediate with no delay, which is ineffective for transient connection issues — the DB connection needs time to recover.