[Sentry: APP-JDP] Web SearchReport max update depth exceeded during file validation

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-JDP

Impact (snapshot at filing)

• Users (total since first seen): 1
• Events: 8
• Users (last 7d): 1
• First seen: 2026-07-27
• Last seen: 2026-07-27
• Platform: web
• App version(s): 9.4.43-1
• Affected route(s): /search/view/:reportID
• Mechanism: auto.browser.global_handlers.onunhandledrejection

Stack trace (top frames)

hideLoaderAndHandleNext
  file validation / sortFilesByOriginalOrder state updates
dispatchSetState → Maximum update depth exceeded
SearchReport view

Suspected cause

File validation flow in SearchReport triggers repeated setState in hideLoaderAndHandleNext, causing React infinite update loop. Distinct from App#96411 (workspace selection during report creation).

Reproduction

Unknown — see Sentry events on /search/view/:reportID.

Related

• Sibling Sentry IDs: none
• Prior GH issues: [Due for payment 2026-07-30] [$250] App crashes with "Maximum update depth exceeded" when selecting the same workspace while creating consecutive reports #96411 (different route/trigger — workspace selection loop)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022081739761753094034
• Upwork Job ID: 2081739761753094034
• Last Price Increase: 2026-07-27

Issue Owner

Current Issue Owner: @shubham1206agra

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @shubham1206agra (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022081739761753094034

[MelvinBot]

Proposal

⚠️ Medium confidence — the regression source and the offending code are identified with a concrete mechanism, but the exact loop hasn't been reproduced (1 user / 8 events, no repro steps). Treat as a strong starting point.

What is the root cause of that problem?

The crash is a React state-update loop inside useFilesValidation, which is what runs when you drop/paste a receipt onto a transaction in a report opened from Search (the report-view consumer is MoneyRequestReceiptView.tsx:257-274).

The likely trigger is PR #93234 ("Prevent OOM tab reload when attaching multiple files on mWeb", merged 2026-07-16). That PR rewrote PDF validation from "mount all thumbnails at once" to "mount one at a time" and added a validatedPDFCount counter that is incremented via setState inside every thumbnail settle callback. 9.4.43-1 (first-seen 2026-07-27) is the first release that contains it, which lines up with the crash appearing.

The mechanism: checkIfAllValidatedAndProceed compares a ref (validatedPDFs.current.length, mutated synchronously) against a state value read from a stale render closure (pdfFilesToRender.length). Each setValidatedPDFCount increment re-renders and remounts the next PDFThumbnail, which re-creates that closure. Because the callbacks call setValidatedPDFCount(...) and checkIfAllValidatedAndProceed() synchronously in the same tick, the completion branch can re-satisfy and re-fire — driving handleNext() → hideLoaderAndHandleNext() (setIsLoaderVisible(false)) → reset() (~10 synchronous setStates) in a remount loop until React throws Maximum update depth exceeded. The hideLoaderAndHandleNext frame in the Sentry stack is this terminal cascade.

This is made worse by a weak re-entry guard: validateFiles guards with if (isValidatingFiles) return; on a state value (not a ref), and reset() flips it back to false in the same synchronous batch as onFilesValidated, so it offers almost no protection against a completion-triggered re-entry.

This is distinct from #96411 (workspace-selection loop during report creation) — same symptom, different route and code path.

What changes do you think we should make in order to solve the problem?

1. In checkIfAllValidatedAndProceed, stop gating completion on the pdfFilesToRender state value. Compare validatedPDFs.current.length against a stable ref count of PDFs to validate (set when pdfFilesToRender is populated), so a stale closure can't cause the counts to disagree and re-fire.
2. Make the isValidatingFiles re-entry guard a ref so it can't be bypassed by a stale closure, and don't clear it in the same synchronous batch that calls onFilesValidated.
3. Guard checkIfAllValidatedAndProceed so its completion branch (onFilesValidated + reset()) can only run once per validation batch (e.g. an isFinalizing ref latch).

What alternative solutions did you explore? (Optional)

Confirming via logs before/while fixing: check the frequency of the Log.warn('Files are already being validated...') message (useFilesValidation.tsx:341) around the crash window, and whether crashing sessions involved PDFs vs plain images — this distinguishes the PDF-thumbnail loop from a pure non-PDF terminal cascade.

Investigation details & what's unverified

• Regression PR: Prevent OOM tab reload when attaching multiple files on mWeb #93234 (commit bf7ea9f, merged 2026-07-16) introduced validatedPDFCount, the one-at-a-time pdfFilesToRender.at(validatedPDFCount) render, and setValidatedPDFCount((c) => c + 1) in each callback. sortFilesByOriginalOrder / hideLoaderAndHandleNext / the loader logic predate it. This hook has a documented history of stale-state bugs (e.g. Fix stale isValidatingMultipleFiles state in file validation error modal #88753).
• Not fully proven: that a PDFThumbnail callback can fire more than once (would make the loop deterministic — lives in react-pdf internals), and whether a single non-PDF image drop alone can trigger the loop without a PDF. Both need runtime confirmation.
• MoneyRequestReceiptView is the report-view consumer that renders {PDFValidationComponent}, consistent with the /search/view/:reportID route.
• Related: [Due for payment 2026-07-30] [$250] App crashes with "Maximum update depth exceeded" when selecting the same workspace while creating consecutive reports #96411 is the same error message on a different route/path — not a duplicate.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/97102) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[shubham1206agra]

@MelvinBot I have watched https://app.fullstory.com/ui/o-1WN56P-na1/session/4692981788963911322:4786187663065064339!8401347299423219620/devtools/console and the link the user clicks on does not have any attachment. How did you arrive at the RCA?

[MelvinBot]

Fair question — here's exactly how I got there, and why your FullStory finding matters.

What the RCA was actually based on (not a session replay):

1. The Sentry stack frames in the issue body — hideLoaderAndHandleNext and sortFilesByOriginalOrder. Both symbols are defined in exactly one file, src/hooks/useFilesValidation.tsx (grep for const hideLoaderAndHandleNext / sortFilesByOriginalOrder = returns only that file), so if those frames are real, the crash is in the file-validation hook.
2. The version timeline — first seen on 9.4.43-1, which is the first build containing PR Prevent OOM tab reload when attaching multiple files on mWeb #93234 (bf7ea9f), which added the setValidatedPDFCount state updates that turn a redundant PDF re-render into an infinite loop.

That's code + release correlation. I did not have session or log evidence that a file was being attached — I flagged the attachment trigger as unverified and rated the whole thing Medium confidence for that reason.

Your FullStory observation is the missing runtime check, and it's a real challenge to the premise. If the crashing session had no attachment at all, the "drop/paste a receipt" trigger is wrong. Two ways to reconcile it — both need the crashing Sentry event, which I can't open from here:

• Is that FullStory session actually one of the 8 crash events? (match user + timestamp). If it's a different session, it doesn't disprove anything.
• On the crashing event specifically, two things to read:
  • The un-minified stack — do useFilesValidation frames genuinely appear, or is hideLoaderAndHandleNext a symbolication artifact from the minified prod bundle? Minified stacks mis-map frames fairly often, and if that's the case the whole useFilesValidation line of reasoning (mine and both contributor proposals) collapses.
  • The breadcrumbs for the entire session, not just the final click. The two proposals below describe a latent render loop seeded by a PDF attach — the attach could have happened earlier and the loop only tipped over React's limit on a later render (e.g. the link click you saw). So the decisive question isn't "did the click have an attachment" but "did this session attach any file (especially a PDF) at any point?" If the answer is a hard no, the RCA is wrong.

So: the RCA is a code-and-version inference from the reported stack frames, not a confirmed reproduction. If you can confirm from the crashing event that no file (PDF or otherwise) was attached anywhere in that session, I'd treat the useFilesValidation attribution as a likely minification artifact and we should re-open the root cause rather than accept any of the three proposals.

[shubham1206agra]

@MelvinBot Read the comment below

🐛 Maximum update depth exceeded (React #185) during rapid receipt uploads on Search report view

Links

• Sentry issue: APP-JDP
• Fullstory session: console/replay · client-session (resolves cleanly)
• Hook involved: src/hooks/useFilesValidation.tsx
• Suspected regression commit: bf7ea9ff8f6 — "Cap concurrent PDF.js parses: focused-only carousel mount + serialized PDF validation"

---

Summary

An infinite React update loop (Error: Maximum update depth exceeded, React production error #185) is thrown while a user repeatedly uploads receipts on expense report views (/search/view/*, view name SearchReport). It surfaces as an unhandled promise rejection (mechanism: auto.browser.global_handlers.onunhandledrejection), so the user sees an "Unhandled Promise Rejection" alert rather than a clean recovery.

Impact / scope

Field	Value
First seen	2026-07-27 11:41 UTC
Last seen	2026-07-27 11:43 UTC
Release	new.expensify@9.4.43-1 (standalone / web)
Occurrences	8 (within ~2 min)
Users impacted	1 — kym.mcgain@plenti.com.au (admin)
Account size	61–300 personal details, 301–1000 reports, 2–10 policies
Browser / OS	Edge 150 / Windows ≥10
Memory at crash	224 MB used / 68.8% usage, ~102 MB free (not critically low)

New in 9.4.43 — not present in earlier releases.

---

Evidence

Stacktrace (minified, from the Sentry event) resolves entirely into useFilesValidation.tsx:

extendLoaderIfNeeded()
  → hideLoaderAndHandleNext()      // setIsLoaderVisible(false)  ← setState that trips the limit
    → handleNext()                 // setErrorQueue / setCurrentErrorIndex / setFileError / onFilesValidated / reset
react-dom: dispatchSetState → enqueueConcurrentHookUpdate → getRootForUpdatedFiber → Error(#185)

Fullstory confirms the trigger behaviorally. From ~79 min into the session the user runs a tight, repetitive bulk-upload loop:

1. Click an expense row in Search results (mostly "Software Subscription", also "IT & misc computing", "Employee Entertainment", "Meals").
2. Navigate to /search/view/{reportID}.
3. Click "Add a receipt or drag and drop" (34× total across the session).
4. Navigate back to /search?q=type:expense… and repeat, ~10s apart.

Every one of the 4 captured React #185 crashes fires ~0.7–1.0s after an "Add a receipt" click:

Crash timestamp	Preceding "Add a receipt" click	Report view
87m28.9s	87m28.2s	/search/view/5851350659843724
88m10.8s	88m10.0s	/search/view/626007684385171
88m52.8s	88m51.5s	/search/view/5495105168360751
89m36.8s	89m35.8s	/search/view/2319127091036807

The report in the Sentry culprit (/search/view/3157155020102124) was opened immediately after the 4th crash. No other console errors/warnings appear in the session — only React #185 — directly tying the loop to the receipt-validation flow. It is intermittent: ~4 crashes across ~34 uploads.

---

Analysis / likely root cause

• React's max-update-depth guard is global to the React root, so the setIsLoaderVisible(false) in the stack is the straw, not necessarily the loop origin — the tree is already in a runaway render/commit cycle when the upload settles.
• The completion path in validateAndResizeFiles fires a synchronous cascade of setState calls (setIsLoaderVisible(false), setValidFilesToUpload, onFilesValidated, reset) once validation finishes.
• validateFiles calls validateAndResizeFiles(...) without await and without .catch (useFilesValidation.tsx:362) — so a thrown Add link styles for sidebar footer #185 has no handler and becomes an uncaught promise rejection.
• Prime suspect for the loop: commit bf7ea9ff8f6 (shipped in the 9.4.43 window), which rewrote PDF validation to render one thumbnail at a time via new validatedPDFCount state + checkIfAllValidatedAndProceed(), which reads pdfFilesToRender (state) through render-time closures and re-enters the setState-heavy completion path. This hook also has prior render-loop/flicker history (c4f623ac802 "App blinks when Attachment error modal shows up", 99a74c899e8 stale isValidatingMultipleFiles), so it's a fragile area.

Confidence: the error, trigger, code path, and regression window are firmly established. The exact looping line could not be isolated from the minified production bundle alone (Sentry Seer autofix is unavailable — "No budget for Seer Autofix"); pinpointing it needs a local repro.

---

Steps to reproduce

1. Log in on new.expensify.com (web) as an admin on an account with many reports (the repro account has 301–1000).
2. Go to Search → type:expense and open an expense report view (/search/view/{reportID}).
3. Click "Add a receipt or drag and drop" and pick a receipt file.
4. Navigate back to the search results, open a different expense, and upload again.
5. Repeat rapidly, back-to-back across many expenses (~1 upload every ~10s, dozens in a row), as in the Fullstory session.
6. After several uploads the app enters an update loop and throws Maximum update depth exceeded (unhandled promise rejection alert).

⚠️ Repro is intermittent (~4 crashes / ~34 uploads in the reported session) — may take many iterations.

Expected result

Repeatedly uploading receipts should never trigger an infinite render loop or an unhandled promise rejection; each upload should validate and attach (or show an error modal) independently.

Actual result

After rapid repeated uploads, React throws error #185 and the failure escapes as an uncaught promise rejection.

---

Suggested next steps

1. Defensive (safe regardless of exact loop): guard the validateAndResizeFiles(...) call at useFilesValidation.tsx:362 with a .catch and reset isValidatingFiles on failure, so a render loop can't escape as an unhandled rejection.
2. Reproduce & bisect against bf7ea9ff8f6 to confirm the validatedPDFCount / checkIfAllValidatedAndProceed path is the loop.
3. Fix the loop and land with Fixes APP-JDP in the commit message to auto-close the issue.

Platform

Web (standalone) · Edge 150 / Windows ≥10 · new.expensify@9.4.43-1