You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Due for payment 2026-06-01] [$250] Web app crashes intermittently with no console errors #90756
The web app is crashing intermittently with no errors visible in the JS console after the crash occurs. This makes it difficult to debug since the console state is lost on crash.
Unknown — needs reproduction. The reporter experienced multiple crashes on the web app but was not able to capture console output at the time of the crash.
Expected behavior
The web app should not crash unexpectedly.
Actual behavior
The web app crashes intermittently. No JS console errors are visible after the crash (likely because the page reloads and console is cleared).
Additional context
Consider leveraging Sentry for better crash reporting so we don't rely on users having the console open
📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:
Get the email address used to login to your Expensify account. If you don't already have an Expensify account, create one here. If you have multiple accounts (e.g. one for testing), please use your main account email.
Get the link to your Upwork profile. It's necessary because we only pay via Upwork. You can access it by logging in, and then clicking on your name. It'll look like this. If you don't already have an account, sign up for one here.
Copy the format below and paste it in a comment on this issue. Replace the placeholder text with your actual details.
Format:
Contributor details
Your Expensify account email: <REPLACE EMAIL HERE>
Upwork Profile Link: <REPLACE LINK HERE>
⚠️Medium confidence — The "Aw, Snap!" crash is a Chrome renderer/tab crash (not a JS exception), most likely caused by out-of-memory (OOM) conditions. Without reproducible steps, the exact trigger is uncertain, but the architectural patterns below are the most probable contributors.
Root Cause: Chrome's "Aw, Snap!" page indicates the renderer process crashed — this is almost always an OOM condition on web. The App loads entire Onyx collections (all reports, transactions, report actions) into memory at startup and keeps them resident. Users with large accounts can exhaust Chrome's JS heap limit (~2GB desktop, ~500MB mobile), causing a full tab crash. Because this is a process-level crash (not a JS error), no console output or error boundary can capture it.
Why existing crash reporting doesn't help:
The ErrorBoundary catches React errors and unhandled promise rejections, but OOM tab crashes kill the process before any JS can run
Memory telemetry sends breadcrumbs to Sentry every 2 minutes, but is passive — it observes memory usage but takes no preventive action when thresholds are exceeded
No window.onerror handler exists for synchronous global errors
No web-specific memory management or data eviction strategy
Image/attachment data (including base64-encoded images) stored in Onyx without size limits
Investigation details
Memory architecture gaps
The app has memory monitoring via sendMemoryContext with thresholds at 70% (warning) and 85% (critical) of jsHeapSizeLimit, but this only logs to Sentry — there is no auto-reload, data eviction, or garbage collection trigger when memory is critical.
Why console is empty after crash
Chrome's "Aw, Snap!" is a renderer process crash. The DevTools console runs in the same renderer process, so it is destroyed along with all JS state. This is fundamentally different from a JS exception — no error handler can catch it because the process is already dead.
Alternative explanations considered
WebGL/Canvas crash: The app uses canvas for text measurement and avatar processing, but these are lightweight operations unlikely to crash the renderer
Service Worker issue: SW registration has error handling but no retry logic; however, SW crashes would not cause "Aw, Snap!"
Browser extension conflict: Possible but unlikely to be the primary cause given the memory architecture concerns
changed the title [-]Web app crashes intermittently with no console errors[/-][+][$250] Web app crashes intermittently with no console errors[/+]on May 15, 2026
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: the regression wasn't critical
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Activity
exfy-zapier commentedon May 15, 2026
This has been labelled "Needs Reproduction". Follow the steps here: https://stackoverflowteams.com/c/expensify/questions/16989
melvin-bot commentedon May 15, 2026
📣 @exfy-zapier! 📣
Hey, it seems we don’t have your contributor details yet! You'll only have to do this once, and this is how we'll hire you on Upwork.
Please follow these steps:
Format:
MelvinBot commentedon May 15, 2026
Issue Analysis
Root Cause: Chrome's "Aw, Snap!" page indicates the renderer process crashed — this is almost always an OOM condition on web. The App loads entire Onyx collections (all reports, transactions, report actions) into memory at startup and keeps them resident. Users with large accounts can exhaust Chrome's JS heap limit (~2GB desktop, ~500MB mobile), causing a full tab crash. Because this is a process-level crash (not a JS error), no console output or error boundary can capture it.
Why existing crash reporting doesn't help:
ErrorBoundarycatches React errors and unhandled promise rejections, but OOM tab crashes kill the process before any JS can runwindow.onerrorhandler exists for synchronous global errorsKey contributing patterns:
waitForCollectionCallback: trueto load ALL reports into memory simultaneously (tracked as a known issue in RemoveOnyx.connect()for the key:ONYXKEYS.COLLECTION.REPORTinsrc/libs/OptionsListUtils.ts#66378)Investigation details
Memory architecture gaps
The app has memory monitoring via
sendMemoryContextwith thresholds at 70% (warning) and 85% (critical) ofjsHeapSizeLimit, but this only logs to Sentry — there is no auto-reload, data eviction, or garbage collection trigger when memory is critical.Why console is empty after crash
Chrome's "Aw, Snap!" is a renderer process crash. The DevTools console runs in the same renderer process, so it is destroyed along with all JS state. This is fundamentally different from a JS exception — no error handler can catch it because the process is already dead.
Alternative explanations considered
Possibly related issues
Onyx.connect()for the key:ONYXKEYS.COLLECTION.REPORTinsrc/libs/OptionsListUtils.ts#66378 — Onyx.connect() refactoring to avoid loading all reports into memory (directly related architectural debt)Recommended next steps:
performance.memory.usedJSHeapSizein DevToolsOnyx.connect()for the key:ONYXKEYS.COLLECTION.REPORTinsrc/libs/OptionsListUtils.ts#66378) to avoid keeping all collections in memoryNext Steps: Reply with
@MelvinBot implement thisto create a draft PR, or@MelvinBot <your feedback>to refine this analysis.melvin-bot commentedon May 15, 2026
Triggered auto assignment to Contributor-plus team member for initial proposal review - @eVoloshchak (
External)[-]Web app crashes intermittently with no console errors[/-][+][$250] Web app crashes intermittently with no console errors[/+]melvin-bot commentedon May 15, 2026
Job added to Upwork: https://www.upwork.com/jobs/~022055203627066608029
mountiny commentedon May 15, 2026
Looks like its this Sentry crash https://expensify.sentry.io/issues/APP-2BN
32 remaining items
melvin-bot commentedon May 29, 2026
@eVoloshchak Whoops! This issue is 2 days overdue. Let's get this updated quick!
melvin-bot commentedon May 31, 2026
Triggered auto assignment to @mallenexpensify (
Awaiting Payment)melvin-bot commentedon May 31, 2026
Payment Summary
Upwork Job
BugZero Checklist (@mallenexpensify)
eVoloshchak commentedon Jun 1, 2026
BugZero Checklist:
[Contributor] The offending PR and associated issue have been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to the comment on the PR: https://github.com/Expensify/App/pull/84887/changes#r3335545743
Link to the comment on the Issue: [Due for payment 2026-03-31] [Due for payment 2026-03-13] [SelectionList Improvements][Phase 4] Migrate sectioned list usages (~25) #65658 (comment)
[Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: the regression wasn't critical
[Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
[BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue: https://github.com/Expensify/Expensify/issues/644123
Regression Test Proposal
Test:
Do we agree 👍 or 👎
Zapier Logs
Run ID: 00040eee-ba9e-ad0c-2d3f-260c616aa1c4mallenexpensify commentedon Jun 2, 2026
Payment Summary
Contributor+: @eVoloshchak due $250 via NewDot
^ Test case created. Thx
JmillsExpensify commentedon Aug 3, 2026
$250 approved for @eVoloshchak