Repository navigation
NewDot web freezes/crashes on Spend > Expenses when applying Filters/Date range on large accounts #97447
Description
Problem
On NewDot web, Spend > Expenses is extremely slow to load on a large account (a minute or more), and applying a Filter / Date range causes the Filters popover to freeze and the page to crash.
Steps to reproduce
- On a large account, go to Spend > Expenses
- Wait for the expenses list to load (very slow)
- Open Filters and select a Date range
Expected result
The filter applies and the list updates without freezing or crashing.
Actual result
The Filters popover freezes/lags, then the page crashes. On retry the popover may not freeze but still lags on filter change and crashes again.
Platform
- Web
Notes
- Reproduced 2026-07-29 on a large account (high report/expense volume).
- Correlated with a heavy backend query timing out for the same flow during the repro window.
- Possibly related to [Due for payment 2026-08-25] [$500] NewDot web tab crashes silently (renderer OOM kill) under high memory / large Onyx dataset #93916 (renderer OOM crash under a large Onyx dataset), but not confirmed to be the same crash.
- Customer details intentionally omitted.
Slack thread: https://expensify.slack.com/archives/C05LX9D6E07/p1785167386765389
Issue Owner
Current Issue Owner: @BartekObudzinskiReacted by melvin-bot
Activity
melvin-bot commentedon Jul 30, 2026
Triggered auto assignment to @mjasikowski (
DeployBlockerCash), see https://stackoverflowteams.com/c/expensify/questions/9980/ for more details.melvin-bot commentedon Jul 30, 2026
💬 A slack conversation has been started in #expensify-open-source
github-actions commentedon Jul 30, 2026
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
mountiny commentedon Jul 30, 2026
Based on the investigation, this seems to be a deploy blocker happening from #93909, when the pr was reverted, the crash did not occur
mountiny commentedon Jul 30, 2026
Discussed in this thread https://expensify.slack.com/archives/C05LX9D6E07/p1785415368295409?thread_ts=1785167386.765389&cid=C05LX9D6E07
MelvinBot commentedon Jul 30, 2026
🔍 Investigation Summary
Classification: Frontend bug
Causing PR: #93909 - "Add filter negation feature" by @bernhardoj (High confidence)
Related Issues: #93916 (renderer OOM crash under large Onyx dataset — likely the same crash surface)
Recommendation: REVERT
The regression lives entirely in
Expensify/App(the Search filter popover / filter-bar code path), the PR is in the currentStagingDeployCash(#97375), and the issue owner already confirmed empirically that reverting #93909 makes the crash go away. Reverting is the safe, fast path to unblock the deploy.Assigned: @bernhardoj (PR author), @aimane-chnaif and @JS00001 (approving reviewers) from the causing PR.
Labels: No change.
DeployBlockerCashis kept because an App PR caused the issue (Frontend bug);DeployBlockerwas not present.Revert target: merge commit
992e4dd2bef3dfd712d9f0c2c45b0247b63f7f20(PR #93909).📋 Detailed Analysis
Evidence
2026-07-28T15:50:06Z— immediately before the2026-07-29staging cut where the bug first reproduced. This is staging-only (matches a deploy blocker; not yet on production).Verification
The reported flow (Spend > Expenses → Filters → Date range) is driven by the files #93909 rewrote. Confirmed the PR modifies the affected code paths:
src/components/Search/SearchPageHeader/useSearchFiltersBar.tsx— the filter bar / popover host that renders on the Expenses page (FilterPopupreworked fromfilterKey→baseFilterKey, switchedCommonPopup→ newListPopup).src/components/Search/FilterDropdowns/ListPopup.tsx— new file replacingCommonPopup.tsx(deleted); this is the popover body that renders the filter option list.src/components/Search/FilterComponents/ListFilterContent.tsx— renamed fromFilterComponents/index.tsx, now wraps every list filter in a newNegatableFilter.src/components/Search/FilterComponents/NegatableFilter.tsx— new wrapper rendered around each filter's option list.src/libs/SearchUIUtils.tsandsrc/libs/SearchQueryUtils.ts— filter value/label computation helpers (getFilterNegatableValue,getLabelValue,isFilterNegated,getFilterFormValues,mapFiltersFormToLabelValueList) reworked.All of these files are present at the investigated App HEAD
48c8baa7a570420be632c1469dd38f6c5862d44c, confirming #93909 is in the branch under test.Root Cause
This PR is a broad refactor of the Search filter popover to add the "is / is not" negation feature. Two structural changes make the large-account freeze/crash plausible and align with #93916 (renderer OOM):
Extra render layer + fresh local state per popover open. The new
ListPopup(permalink) computesgetFilterNegatableValue(...)on every render and seeds twouseStatevalues, then rendersListFilterContent→NegatableFilter→ the actual selector (WorkspaceSelector,UserSelectorfor To/From,TagSelector, etc.). On a large account these selectors materialize very large option lists (all members, all workspaces, all tags). The added wrapper layer and the negation-toggle state change (onNegationChange) force the full option list to re-render synchronously when the user interacts with the popover — exactly the "popover freezes, then page crashes" symptom.Label/value recomputation over the whole form on every filter change.
mapFiltersFormToLabelValueListnow callsgetLabelValue→isFilterNegatedper key (SearchUIUtils.ts ~L5622-5738), andgetFilterNegatableValuewas rewritten (~L5610). This runs when the filter bar re-renders after a filter (e.g. Date range) is applied, which on a large dataset compounds with the already-heavy Expenses list render and pushes the renderer over its memory budget (the OOM in [Due for payment 2026-08-25] [$500] NewDot web tab crashes silently (renderer OOM kill) under high memory / large Onyx dataset #93916).The slow initial load of Spend > Expenses on large accounts is a separate/pre-existing pressure (heavy backend query for high report/expense volume, noted in the issue), but the freeze-then-crash on applying a filter is introduced by #93909 — hence the clean disappearance on revert.
Because this PR is a large refactor with wide surface area (43 files) and no obvious single-line targeted fix, a full revert of #93909 is preferred over a spot fix. A forward fix (memoizing the popover option lists / avoiding the extra re-render layer) can be reworked and re-landed after the deploy is unblocked.
BartekObudzinski commentedon Jul 30, 2026
Reproduction steps
BartekObudzinski commentedon Jul 30, 2026
I found this Sentry issue, which contains matching crash events. I reproduced the crash on staging and dev, while production works fine. The problem was not related to selecting a date range. It occurred when hovering over the From or To sections in the Filters popover. After reviewing the recent changes, PR #93909 stood out because it modifies this exact area. Reverting it locally stopped the crash
fix already merged #97432
mountiny commentedon Jul 30, 2026
Fixed in staging