[$250] Web – Uh-oh crash after saving expense description from Search (React #185)

[mountiny]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: Web production build (e.g. 9.3.77-3 class; exact build TBD at repro)
Reproducible in staging?: TBD
Reproducible in production?: Yes (confirmed via internal logs + session replay; details not in this issue)
If this was caught during regression testing, add the test name, ID and link from BrowserStack:
Email or phone of affected tester (no customers): N/A — customer report, redacted
Logs: https://stackoverflow.com/c/expensify/questions/4856 (internal VL query available to assignee)
Expensify/Expensify Issue URL:
Issue reported by: Internal investigation
Slack conversation (hyperlinked to channel name):

Related (observability, not root fix): #91407, #91405

Action Performed

1. Go to Search and open an expense from the results (search money-request report view).
2. Open Description edit for a submit expense (RHP): route pattern edit/submit/description/:transactionID/:reportID.
3. Change the description text and tap Save.
4. App attempts to navigate back to the search expense view: route pattern search/view/:reportID.

Expected Result

Description saves successfully; user returns to the search expense view with the report UI intact.

Actual Result

Full-page GenericErrorPage (“Uh-oh, something went wrong!”) — top-level ErrorBoundary in App.tsx (errorMessage="NewExpensify crash caught by error boundary").

Workaround

Refresh the page (or sign out and back in). The description change may or may not have persisted.

Platforms

Select the officially supported platforms where the issue was reproduced:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari

Screenshots/Videos

Add screenshots if available; no customer session links in this issue.

---

Technical details (for implementers)

Error

• React error #185 — Maximum update depth exceeded (infinite re-render loop).
• Logged client-side as: NewExpensify crash caught by error boundary - Minified React error #185; visit https://react.dev/errors/185 ...
• Sentry: Web render errors caught by the boundary were not appearing as Sentry error events prior to [No QA] Report caught render errors to Sentry from the web ErrorBoundary #91407 (boundary only called Log.alert). Do not rely on Sentry alone to validate this bug until that ships.

Component stack (deepest → root, from production web bundle)

Abbreviated stack at time of crash:

ViewHolderCollection
  → RecyclerViewComponent (FlashList)
  → components_FlashList / FlashList_InvertedFlashList
  → ReportActionsList / report_ReportActionsView / inbox_ReportActionsList
  → ConciergeDraftProvider / AgentZeroStatusProvider
  → components_OfflineWithFeedback
  → ReportNotFoundGuard / ScreenWrapper / WithNavigationFallback
  → inbox_ReactionListWrapper / WideRHPOverlayWrapper
  → ReportActionEditMessageContextProvider
  → ReportScreenEditMessageProvider
  → inbox_ReportScreen / RHPReportScreen
  → Navigation (EnsureSingleNavigator / SceneView)

Suspected root cause

Save → navigate back flow:

• IOURequestStepDescription.tsx: updateMoneyRequestDescription + Navigation.goBack(backTo) toward search view.
• Remounts ReportScreen → ReportScreenEditMessageProvider → ReportActionsList with InvertedFlashList.

Strong suspect: ReportActionEditMessageContextProvider performs setState during render when bridging Onyx drafts:

// ReportActionEditMessageContext.tsx (simplified)
if (activeDraftEditResolution !== null) {
    if (editingState === CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
        setEditingState(CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.EDITING); // during render
    }
    syncComposerDraftFromPersistedOnyxDraft(...); // also setState during render
}
if (editingReportID == null && editingState !== CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
    stopEditing(); // setState during render
}

After saving description and navigating back, Onyx draft / report-action updates may re-enter this path on every render → React #185 → error boundary.

Suggested fix direction: Move draft sync / setEditingState / stopEditing into useEffect (or derive state without setState-in-render), with stable dependencies on activeDraftEditResolution fields.

Contributor repro (no customer data needed)

1. Search → open any submit expense from search results.
2. Edit Description → change text → Save.
3. Confirm landing on search/view/:reportID without the generic error page.
4. If flaky: try with an active report-action draft / edit-message state, or repeat save immediately after opening the expense RHP.

---

Out of scope

• invalid currency code in NumberFormat() on Search list — related symptom class but different stack (DataCells_TotalCell); native tracking in https://expensify.sentry.io/issues/APP-6MR does not include web boundary hits.
• Web Sentry reporting for boundary crashes — [No QA] Report caught render errors to Sentry from the web ErrorBoundary #91407

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @VickyStash

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058845613673678766
• Upwork Job ID: 2058845613673678766
• Last Price Increase: 2026-05-25

[MelvinBot]

Proposal

What is the root cause of that problem?

ReportActionEditMessageContext.tsx calls setState directly during the render body (not inside useEffect or callbacks) in three places, creating an oscillation loop that triggers React error #185:

1. Line ~114: setEditingState(EDITING) when activeDraftEditResolution !== null and editingState === OFF
2. Line ~117: syncComposerDraftFromPersistedOnyxDraft() — calls 3 more setStates during render
3. Lines ~131-133: stopEditing() when editingReportID == null and editingState !== OFF — calls 4 setStates during render

The loop mechanism: After saving a description in IOURequestStepDescription.tsx and navigating back, RHPReportScreen remounts ReportScreen (via key={reportID}), re-initializing the context provider. If activeDraftEditResolution oscillates between null/non-null as Onyx settles:

• Render N: activeDraftEditResolution non-null, editingState === OFF → setEditingState(EDITING) + syncComposerDraftFromPersistedOnyxDraft sets prevEditingReportActionID
• Render N+1: Onyx settles differently → activeDraftEditResolution null → editingReportID == null, editingState === EDITING → stopEditing() resets editingState to OFF and prevEditingReportActionID to null
• Render N+2: Onyx snapshot flips back → editingState === OFF again, prevEditingReportActionID is null so syncComposerDraftFromPersistedOnyxDraft guard passes → repeat from Render N

This exceeds React's 50-iteration limit → error #185 → ErrorBoundary crash.

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

Move all three setState-during-render sites in ReportActionEditMessageContext.tsx into useEffect hooks with stable dependencies on activeDraftEditResolution, editingState, and editingReportID. This defers state updates to after render, preventing the synchronous re-render cascade.

Specifically:

1. Replace the render-body setEditingState(EDITING) + syncComposerDraftFromPersistedOnyxDraft() block (lines ~108-118) with a useEffect keyed on activeDraftEditResolution and editingState.
2. Replace the render-body stopEditing() call (lines ~131-133) with a useEffect keyed on editingReportID and editingState.

What alternative solutions did you explore? (Optional)

• Deriving state without setState: Instead of toggling editingState via setState, compute it as a derived value from activeDraftEditResolution and editingReportID. This eliminates the oscillation entirely but requires a larger refactor of downstream consumers that depend on the editingState setter.
• Adding a ref guard: Use a ref to track whether we've already processed a given activeDraftEditResolution value, preventing re-processing after stopEditing resets prevEditingReportActionID. This is more fragile than the useEffect approach.

Investigation details

Component stack analysis: ReportActionsList (line 808) consumes the edit context via useShouldShowComposerForActiveEditDraft, making it re-render on every oscillation cycle — this is why FlashList/InvertedFlashList appear in the crash stack. However, InvertedFlashList itself (index.tsx) uses proper useEffect-gated state and is not a contributor to the loop.

stopEditing() is the key amplifier (lines 124-129): it resets prevEditingReportActionID to null, which defeats the guard in syncComposerDraftFromPersistedOnyxDraft (the didFocusShiftToDistinctReportAction check at line ~93), allowing the full cycle to restart rather than stabilize.

Possible related issues: #89588 also reports a crash after interacting with search results, though the exact stack may differ.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Web, opening a submit expense from Search, editing its Description, and saving can return the user to search/view/:reportID with the full-page "Uh-oh, something went wrong!" error instead of rendering the Search expense/report view. The crash is React error #185, maximum update depth exceeded.

What is the root cause of that problem?

The Save flow is valid, but it lands on a report tree that is not render-pure.

Search opens expense rows through ROUTES.SEARCH_REPORT.getRoute({reportID, backTo}) / the money-request Search report route, the Description row passes the active route as backTo, and IOURequestStepDescription writes the new description through updateMoneyRequestDescription() before navigating back.

When that Search report screen remounts, ReportScreen wraps ReportActionsList in ReportScreenEditMessageProvider. Inside ReportActionEditMessageContextProvider, useActiveDraftReportAction() can resolve a persisted edit draft from three places: an ancestor action, the visible report, or the effective transaction-thread report used by single-expense/search views.

If any active draft is resolved, the provider calls React setters directly during render:

• setEditingState(EDITING)
• syncComposerDraftFromPersistedOnyxDraft(...), which can call setEditingMessage(), setPrevEditingReportActionID(), and setCurrentEditMessageSelectionState()

It also calls stopEditing() during render when no editing report is currently resolved but local edit state is still active, which runs several more setters.

The description save mutates Onyx and then returns into this remounting Search report/FlashList tree. A stale or rehydrating report-action edit draft can repeatedly enter the provider's render-time sync/cleanup branches, so rendering the destination screen itself schedules more updates until React throws #185.

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

Make ReportActionEditMessageContextProvider render-pure and move the draft bridge / cleanup work into effects.

In src/pages/inbox/report/ReportActionEditMessageContext.tsx:

1. Keep useActiveDraftReportAction({effectiveTransactionThreadReportID, reportID}) as the single resolver for ancestor, visible-report, and transaction-thread draft precedence.
2. During render, only derive editingReportID, editingReportActionID, and editingReportAction from activeDraftEditResolution. Do not call setters while deriving those values.
3. Convert syncComposerDraftFromPersistedOnyxDraft and stopEditing to stable callbacks.
4. Add an effect keyed by stable draft fields such as activeDraftEditResolution?.editingReportActionID and activeDraftEditResolution?.draftMessage. In that effect, if a draft exists:
   • move editingState from OFF to EDITING;
   • copy the persisted draft into editingMessage;
   • update prevEditingReportActionID;
   • initialize the edit-message selection to the end of the draft.
5. Add a separate cleanup effect for the inverse transition: when there is no activeDraftEditResolution and editingState !== OFF, call stopEditing().
6. Preserve the existing guard that does not overwrite the composer when the same editingReportActionID is already active, so a user typing into an edit draft is not overwritten by the persisted preview.

This keeps the existing draft-restore behavior and the resolver's precedence rules, but all React state transitions happen after commit instead of during the render that is building ReportActionsList / InvertedFlashList.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

Add provider-level coverage around ReportActionEditMessageContextProvider for these cases:

• A persisted draft appears on the visible report; after effects flush, the provider enters EDITING, restores the message, and sets selection to the end of the draft.
• A persisted draft appears on effectiveTransactionThreadReportID, matching the Search single-expense RHP path.
• The active draft disappears while the provider is mounted; after effects flush, the provider returns to OFF.
• A draft appears and clears across rerenders without render-phase state update warnings or a maximum-update-depth error.

Manual regression:

1. Search for expenses and open a submit expense result.
2. Open Description, change it, and Save.
3. Confirm the app lands back on search/view/:reportID with the report UI intact and no GenericErrorPage.
4. Repeat with an existing report-action edit draft before saving the expense description.

[Abdukhamid000]

Proposal

What is the root cause of that problem?

ReportActionEditMessageContextProvider performs four separate setState calls during render, gated by conditions that the same setStates can re-flip on the next render. After save → goBack to search/view/:reportID, the Onyx-driven activeDraftEditResolution and the locally-tracked editingState/prevEditingReportActionID interleave through a sequence of transitions where each render flips a condition that the previous render's setState created, hitting React's "Maximum update depth exceeded" guard (#185).

The hot path is [ReportActionEditMessageContext.tsx:108-133](https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionEditMessageContext.tsx#L108-L133):

if (activeDraftEditResolution !== null) {
    editingReportID = activeDraftEditResolution.editingReportID;
    editingReportActionID = activeDraftEditResolution.editingReportActionID;
    editingReportAction = activeDraftEditResolution.editingReportAction;

    if (editingState === CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
        setEditingState(CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.EDITING);   // ← setState in render
    }
    syncComposerDraftFromPersistedOnyxDraft(...);                            // ← internally calls 3 setStates
}

if (editingReportID == null && editingState !== CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
    stopEditing();                                                           // ← calls 4 setStates
}

Walking the save-and-navigate flow:

1. IOURequestStepDescription writes the new description via updateMoneyRequestDescription and calls Navigation.goBack(backTo) into search/view/:reportID. ReportScreen remounts under the search RHP wrapper, with ReportScreenEditMessageProviderWithTransactionThread → ReportActionEditMessageContextProvider.
2. Mount: editingState === OFF, prevEditingReportActionID === null. The Onyx draft for the edit hasn't been cleared yet (description save updates the report action, not the edit draft), so activeDraftEditResolution is non-null on the first render.
3. Render 1 hits the first branch: setEditingState(EDITING) and syncComposerDraftFromPersistedOnyxDraft(...) (which fires setEditingMessage, setPrevEditingReportActionID, setCurrentEditMessageSelectionState because prev !== actionID). Four queued setStates.
4. Render 2: state has flipped but activeDraftEditResolution is still non-null. syncComposerDraftFromPersistedOnyxDraft's early-return saves us — until the Onyx draft clears, at which point activeDraftEditResolution becomes null and editingReportID (set only inside the first branch) is now null while editingState === EDITING.
5. Render 3 hits the second branch: stopEditing() → another four setStates (editingState=OFF, editingMessage=null, prev=null, selection=null).
6. Now the dangerous case: if useActiveDraftReportAction returns a fresh non-null object on the next render (a stale Onyx subscription firing one more time, or an upstream useTransactionThreadReportID re-resolving the effective thread for the search route), we re-enter step 3 with prev=null — and the cycle repeats. React aborts with #185.

A second sharper edge: useActiveDraftReportAction returns a new object each render even when the underlying data is identical. The if (activeDraftEditResolution !== null) check is only checking reference; with prev now reset to null in the previous render, didFocusShiftToDistinctReportAction evaluates true again the moment the resolver yields any non-null shape. There's no fixed point.

The bug write-up has already identified this exact site — three setState-in-render calls (setEditingState, syncComposerDraftFromPersistedOnyxDraft, stopEditing) where the React-recommended pattern is fragile because the deciding conditions are derived from state the calls themselves mutate.

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

Move every transition into useEffect so the conditions are sampled after commit instead of during render. Derive the visible editingReportID/ActionID/Action straight from activeDraftEditResolution so there's no mutable local stitched together inside the render body:

 function ReportActionEditMessageContextProvider({reportID, effectiveTransactionThreadReportID, children}) {
     const activeDraftEditResolution = useActiveDraftReportAction({effectiveTransactionThreadReportID, reportID});

     const [editingState, setEditingState] = useState(CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF);
     const [prevEditingReportActionID, setPrevEditingReportActionID] = useState<string | null>(null);
     const [editingMessage, setEditingMessage] = useState<string | null>(null);
     const [currentEditMessageSelection, setCurrentEditMessageSelectionState] = useState<TextSelection | null>(null);

-    let editingReportID: string | null = null;
-    let editingReportActionID: string | null = null;
-    let editingReportAction: OnyxTypes.ReportAction | null = null;
-
-    const syncComposerDraftFromPersistedOnyxDraft = (activePersistedDraftReportActionID, persistedDraftMessagePreview) => {
-        if (persistedDraftMessagePreview == null) { return; }
-        const didFocusShiftToDistinctReportAction = prevEditingReportActionID !== activePersistedDraftReportActionID;
-        if (!didFocusShiftToDistinctReportAction) { return; }
-        setEditingMessage(persistedDraftMessagePreview);
-        setPrevEditingReportActionID(activePersistedDraftReportActionID);
-        setCurrentEditMessageSelectionState({start: persistedDraftMessagePreview.length, end: persistedDraftMessagePreview.length});
-    };
-
-    if (activeDraftEditResolution !== null) {
-        editingReportID = activeDraftEditResolution.editingReportID;
-        editingReportActionID = activeDraftEditResolution.editingReportActionID;
-        editingReportAction = activeDraftEditResolution.editingReportAction;
-        if (editingState === CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
-            setEditingState(CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.EDITING);
-        }
-        syncComposerDraftFromPersistedOnyxDraft(activeDraftEditResolution.editingReportActionID, activeDraftEditResolution.draftMessage);
-    }
-
-    if (editingReportID == null && editingState !== CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
-        stopEditing();
-    }
+    // Derive visible identifiers from the resolver — no mutable locals, no setState in render.
+    const editingReportID       = activeDraftEditResolution?.editingReportID       ?? null;
+    const editingReportActionID = activeDraftEditResolution?.editingReportActionID ?? null;
+    const editingReportAction   = activeDraftEditResolution?.editingReportAction   ?? null;
+    const activeDraftActionID   = activeDraftEditResolution?.editingReportActionID ?? null;
+    const activeDraftMessage    = activeDraftEditResolution?.draftMessage          ?? null;
+
+    // Enter EDITING when a draft appears; stop when it disappears. Both run post-commit so
+    // the conditions can't re-trigger the same setState within the render pass.
+    useEffect(() => {
+        if (activeDraftActionID === null) {
+            if (editingState !== CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
+                stopEditing();
+            }
+            return;
+        }
+        if (editingState === CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.OFF) {
+            setEditingState(CONST.REPORT_ACTION_EDIT_MESSAGE_STATE.EDITING);
+        }
+    }, [activeDraftActionID, editingState]);
+
+    // Sync composer draft only when the *identity* of the edit target changes.
+    useEffect(() => {
+        if (activeDraftActionID === null || activeDraftMessage === null) {
+            return;
+        }
+        if (prevEditingReportActionID === activeDraftActionID) {
+            return;
+        }
+        setEditingMessage(activeDraftMessage);
+        setPrevEditingReportActionID(activeDraftActionID);
+        setCurrentEditMessageSelectionState({start: activeDraftMessage.length, end: activeDraftMessage.length});
+    }, [activeDraftActionID, activeDraftMessage, prevEditingReportActionID]);

The key shape change is that all four setStates fire from useEffect, gated on primitive values (activeDraftActionID, activeDraftMessage, editingState). useActiveDraftReportAction can return a fresh object reference every render without retriggering the effect, because the deps array compares primitives only. That's what kills the infinite loop.

submitEdit, stopEditing, setCurrentEditMessageSelection, and the context value below stay as-is — they're already proper handlers/values.

One thing to double-check while landing this: stopEditing is captured by the first useEffect so it needs to either be stable (wrap in useCallback with [] deps — it only calls setters) or be added to the dep array. The useCallback form is the safer cosmetic fix and matches how other context providers in inbox/ shape their handlers.

I'd also add a regression test using the contributor repro at the bottom of the bug:

1. Search → open a submit expense.
2. Edit Description, change text, Save.
3. Assert no error-boundary fallback is rendered and the search view route is in focus.

Even simpler smoke check: render ReportActionEditMessageContextProvider with a stub useActiveDraftReportAction that returns null → object → null in three successive ticks, assert no warning about update depth.

What alternative solutions did you explore?

• Wrap setEditingState in a prev === OFF ? EDITING : prev check inside an existing useReducer. Same protection, more code. The shared issue is "setState in render," not "wrong reducer shape."
• Stabilize useActiveDraftReportAction's return so the object reference is equal when data hasn't changed. Worth doing as a follow-up (it removes a class of subtle re-render bugs in any consumer), but it doesn't fix the root cause — the setState-in-render path can still loop when the underlying data genuinely transitions through null → A → null mid-mount.
• Add a render-count circuit breaker that bails out after N renders. Hides the symptom and ships latent bugs forward. Not acceptable for a top-level error-boundary crash.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When a user edits and saves an expense description from the Search flow on Web (Windows Chrome), the app crashes to the generic ErrorBoundary ("Uh-oh, something went wrong!") instead of navigating back to the search expense view. The expected behavior is that the description saves and the user returns to search/view/:reportID with the report UI intact. The crash is React error #185 (Maximum update depth exceeded) thrown from the ReportActionEditMessageContextProvider subtree during the post-save remount.

What is the root cause of that problem?

ReportActionEditMessageContextProvider in src/pages/inbox/report/ReportActionEditMessageContext.tsx performs setState during render in three places: setEditingState(EDITING) at line 114, the multiple setters inside syncComposerDraftFromPersistedOnyxDraft invoked at line 117, and stopEditing() at line 132. After updateMoneyRequestDescription + Navigation.goBack runs, Onyx draft updates cause useActiveDraftReportAction to flip activeDraftEditResolution between non-null and null across renders. The top-level if (activeDraftEditResolution !== null) block at line 108 sets state to EDITING; the if (editingReportID == null && editingState !== OFF) block at line 131 then sets it back to OFF — each render mutates state that re-triggers the resolver, producing an unbounded render loop that the App.tsx ErrorBoundary catches.

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

1. src/pages/inbox/report/ReportActionEditMessageContext.tsx lines 107–118: move the setEditingState(EDITING) call and the syncComposerDraftFromPersistedOnyxDraft invocation into a useEffect keyed on stable primitives derived from activeDraftEditResolution (editingReportID, editingReportActionID, draftMessage). Compute editingReportID/editingReportActionID/editingReportAction for the context value as plain derived locals (not via setState).
2. Same file lines 131–133: move the stopEditing() fallback into the same (or a sibling) useEffect so the OFF transition only fires when editingReportID actually becomes null between renders, not on every render where the predicate is true.
3. Same file lines 88–105: convert syncComposerDraftFromPersistedOnyxDraft so its setEditingMessage / setPrevEditingReportActionID / setCurrentEditMessageSelectionState calls run from the effect, guarded by the didFocusShiftToDistinctReportAction check against current state.
4. Verify the same provider mounted by SearchMoneyRequestReportPage.tsx:377 (Search RHP) and by ReportScreen.tsx (Inbox) both go through the new effect path — no additional sibling/platform files (.native/.web) exist for this provider.

What alternative solutions did you explore? (Optional)

Gating the in-render branch with a ref to skip re-entry would silence the loop but leave a setState-in-render warning and still rely on render ordering — using useEffect is the idiomatic fix.

[melvin-bot]

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