Repository navigation
[Onyx] Investigate QuotaExceededError: The current transaction exceeded its quota limitations. storage error #87863
Description
Coming from #87844.
Summary
Let's investigate the following Onyx storage error: QuotaExceededError: The current transaction exceeded its quota limitations., which accounts for 865,703 (25.7%) of the 3,364,645 analysed errors during a time span of 1 month. Full details about the investigation and methodology are in #87844.
| Platforms | Top Methods |
|---|---|
| Desktop Firefox (865K — 100%) | setWithRetry (865K) |
| Retries Exhausted | Evictions | No Eviction | Quota Checks | >= 95% Full | Mean % Full | Quota Check Failed |
|---|---|---|---|---|---|---|
| 6,089 | 859,566 | 0 | 859,276 | 0 | 0.0% | 0 |
- 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
Action Items
- Investigate with Sentry, VictoriaLogs and Fullstory to understand user scenarios where this happens — what kind of data is being written when Firefox rejects the transaction?
- Investigate what Firefox's exact quota/transaction limit is and whether we are writing values that are too large for it
Activity
fabioh8010 commentedon May 12, 2026
There was a PR created here Expensify/react-native-onyx#781, but I think we should close it until we have better investigations and picture about how we want to move here. Also Jakub is no longer at Callstack so it's difficult to handle the PR this way.
sosek108 commentedon May 29, 2026
Hi, I'll be continuing investigation here
LukasMod commentedon May 29, 2026
I did some investigation before my OOO to help @sosek108 on this:
Local repro (Firefox origin storage cap)
I reproduced production-like Onyx
QuotaExceededErrorlogs in Firefox by lowering the browser’s origin storage quota (IndexedDB budget for the site — not the user’s OS disk free space) viaabout:config:about:config.dom.quotaManager.temporaryStorage.fixedLimitto a small value (on my build the pref is in KB; effective cap ≈value × 1024bytes — fully quit Firefox after changing it).Example console output:
Here
bytesRemainingis small becausenavigator.storage.estimate()reports room left in the browser’s per-origin quota, which we artificially capped — not because the machine’s hard drive is full.Findings
The issue affects few users who generate almost all error-log volume (see tables below).
In FullStory, errors started after the tab was idle for several minutes while Pusher updates continued.
onyxDatawrites) until Firefox rejects further writes — not necessarily from active Spend/Search use.bytesRemaininginnavigator.storage.estimate(), because that API measures the browser’s origin quota, not “GB free on the SSD.” We cannot see OS free space from the web app; this path is plausible for user-specific repros but not proven by current prod logs (most samples show ~0.5% of origin quota used and ~10 GBbytesRemaining).I could not reproduce on a normal origin quota pool by writing large payloads locally (single large writes or bulk
multiSet) — synthetic Onyx size alone was not enough on my machine. That does not rule out Hypothesis A at real account scale, or Hypothesis B if disk pressure happened on the user’s machine but not in my test environment.With the capped origin quota pref, opening the Spend tab triggered a retry/eviction loop (possibly unbounded) — likely how some sessions produced 150k+ similar log lines.
Open question —
bytesRemainingvs behavior: For many affected users,Storage Quota Checkdoes not show a nearly full browser quota. Example from production:With
fixedLimit, the same log line shows lowbytesRemaining(aligned with the cap). In production,bytesRemainingis often ~10 GB while writes still fail with the same error string. Unclear whether we should treatbytesRemainingas ground truth, or whether Firefox enforces a different limit thanestimate()reflects (e.g. per-transaction limit, or timing vs eviction).User concentration (anonymized) — last 30 days
Query: any log line containing
The current transaction exceeded its quota limitations(includesFailed to save, eviction, quota check, etc.).Total: 17,324 events · 15 users with
email· 1 row without emailExample prod quota line:
bytesUsed: 51466333,bytesRemaining: 10685951907→ ~0.5% of reported origin quota used — errors still fire.Interpretation: High event count comes from few sessions (Users 1–2 ≈ 65% in 30d).
User concentration (anonymized) — last 2 months (Apr spike; not primary focus)
Total: 364,216 events · dominated by 2026-04-18 and 2026-04-21. Top 2 = 87.0% — different accounts than the 30-day leaders above.
Firefox users from last 7 days
[App]logtransaction exceededlineNext steps
We may not be able to eliminate these errors entirely — they appear user-specific. Most Firefox users never hit them.
Still, we can reduce noise, improve diagnostics, and degrade more gracefully when storage writes fail.
sosek108 commentedon Jun 1, 2026
Update posted here: #87873 (comment)
sosek108 commentedon Jun 3, 2026
Let's close this as duplicate of #87873 (comment)
cc: @Julesssss