[Due for payment 2026-06-29] [Due for payment 2026-06-26] [$500] 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

Upwork Automation - Do Not Edit

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

Issue Owner

Current Issue Owner: @ZhenjaHorbach

[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

What is the root cause of that problem?

Saving the expense description is only the trigger. The description page updates the transaction description and then navigates back to backTo, so the destination report list has to lay out again after the new report action/system message changes the list height.

App/src/pages/iou/request/step/IOURequestStepDescription.tsx

Lines 115 to 125 in fec6b33

	const navigateBack = useCallback(() => {
	Navigation.goBack(backTo);
	}, [backTo]);
	useEffect(() => {
	if (!isSaved || !shouldNavigateAfterSaveRef.current) {
	return;
	}
	shouldNavigateAfterSaveRef.current = false;
	navigateBack();
	}, [isSaved, navigateBack]);

App/src/pages/iou/request/step/IOURequestStepDescription.tsx

Lines 151 to 171 in fec6b33

	if (action === CONST.IOU.ACTION.EDIT) {
	updateMoneyRequestDescription({
	transactionID: transaction?.transactionID,
	transactionThreadReport: report,
	parentReport,
	comment: newComment,
	policy,
	policyTagList: policyTags,
	policyCategories,
	currentUserAccountIDParam,
	currentUserEmailParam,
	isASAPSubmitBetaEnabled,
	parentReportNextStep,
	delegateAccountID,
	});
	} else {
	setMoneyRequestDescription(transaction?.transactionID, newComment, isTransactionDraft, hasReceipt(transaction));
	}
	setIsSaved(true);
	shouldNavigateAfterSaveRef.current = true;

For Search money-request reports, a transaction-thread view can fall through to the normal ReportActionsList, and that list renders an InvertedFlashList backed by @shopify/flash-list.

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 160 to 163 in fec6b33

	// Special case handling a report that is a transaction thread
	// If true we will use the standard `ReportActionsList` to display report data and a special header, anything else is handled via `MoneyRequestReportActionsList`
	const isTransactionThreadView = isReportTransactionThread(report);

App/src/components/MoneyRequestReportView/MoneyRequestReportView.tsx

Lines 278 to 286 in fec6b33

	<View style={[styles.overflowHidden, styles.justifyContentEnd, styles.flex1]}>
	{shouldDisplayMoneyRequestActionsList ? (
	<MoneyRequestReportActionsList onLayout={onLayout} />
	) : (
	<>
	<ReportActionsList
	reportID={report.reportID}
	onLayout={onLayout}
	/>

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 487 to 503 in fec6b33

	<InvertedFlashList
	accessibilityLabel={translate('sidebarScreen.listOfChatMessages')}
	ref={listRef}
	testID="report-actions-list"
	style={styles.overscrollBehaviorContain}
	data={renderedVisibleReportActions}
	renderItem={renderItem}
	keyExtractor={keyExtractor}
	drawDistance={1500}
	renderScrollComponent={renderActionSheetAwareScrollView}
	contentContainerStyle={styles.chatContentScrollView}
	onEndReached={loadOlderChatsOnEndReached}
	onEndReachedThreshold={0.75}
	onStartReached={loadNewerChatsAfterTransitions}
	onStartReachedThreshold={0.75}
	ListHeaderComponent={listHeaderComponent}
	ListHeaderComponentStyle={shouldBeAlignedToTop ? styles.flex1 : undefined}

App/src/components/FlashList/InvertedFlashList/index.tsx

Lines 57 to 66 in fec6b33

	return (
	<FlashList<T>
	{...restProps}
	inverted
	onStartReached={onStartReached}
	data={displayedData}
	keyExtractor={keyExtractor}
	CellRendererComponent={CellRendererComponent}
	maintainVisibleContentPosition={maintainVisibleContentPosition}
	/>

The actual loop is in FlashList's web measurement path. On web, FlashList derives the list's cross-axis bounded size from the measured scroll viewport width. When a report or transaction thread is exactly at the scroll/no-scroll boundary, a classic vertical scrollbar appearing or disappearing changes the viewport client width by about the scrollbar width. FlashList treats each width as a new boundedSize, reruns layout, changes the content height enough to toggle the scrollbar again, and repeats until React aborts with maximum update depth exceeded.

App/patches/@shopify/flash-list/details.md

Lines 133 to 143 in fec6b33

	### [@shopify+flash-list+2.3.0+012+fix-scrollbar-oscillation-crash.patch](@shopify+flash-list+2.3.0+012+fix-scrollbar-oscillation-crash.patch)
	- Reason: Fixes a "Maximum update depth exceeded" (#185) infinite render loop on web with classic (non-overlay) scrollbars — i.e. Windows/Linux Chrome and macOS with "Always show scroll bars". For a vertical list FlashList derives its cross-axis bounded size from `firstChildViewLayout.width` (the scroll viewport's **client** width, which excludes the scrollbar). When the vertical scrollbar toggles, that width steps by the scrollbar size (e.g. 375 ↔ 355); each change re-triggers layout, which changes content height, which toggles the scrollbar again — an infinite loop. This patch breaks the loop inside `LinearLayoutManager.updateLayoutParams` by detecting the scrollbar ping-pong and settling `boundedSize` instead of thrashing it — reserving no width. A change is treated as scrollbar-induced only when all hold, so a real window resize is never misread:
	1. **Strict alternation**: the last 4 *rounded* cross-axis sizes form a clean `A,B,A,B` (exactly two values, three consecutive flips). A manual drag sweeps through many distinct values and never matches; rounding keeps the equality robust against subpixel drift.
	2. **Scrollbar-sized delta**: the two values differ by no more than `SCROLLBAR_OSCILLATION_TOLERANCE` (25px — classic scrollbars are ~15–17px, with headroom for thicker/zoomed bars).
	When detected, `boundedSize` settles on the **smaller** of the two values, which already accounts for the scrollbar so items never overflow the client width.
	- Files changed: `dist/recyclerview/layout-managers/LinearLayoutManager.js` only.
	- Upstream PR/issue: https://github.com/Shopify/flash-list/issues/2334
	- E/App issue: https://github.com/Expensify/App/issues/91584, https://github.com/Expensify/App/issues/92263
	- PR introducing patch: https://github.com/Expensify/App/pull/92520

A narrower version of the same class came from subpixel drift: before the web rounding patch, roundOffPixel() returned the raw getBoundingClientRect() value, so fractional display scaling could make visually equivalent widths look different to FlashList on every commit.

App/patches/@shopify/flash-list/details.md

Lines 78 to 85 in fec6b33

	### [@shopify+flash-list+2.3.0+010+fix-web-subpixel-rounding.patch](@shopify+flash-list+2.3.0+010+fix-web-subpixel-rounding.patch)
	- Reason: Fixes a "Maximum update depth exceeded" infinite render loop on web (mostly Windows with fractional display scaling). `roundOffPixel` on web was a no-op, so subpixel drift in the child container's `getBoundingClientRect()` width re-triggered `ViewHolderCollection`'s `[fixedContainerSize]` layout effect on every measurement. The patch implements `roundOffPixel` to snap to the device-pixel grid (`Math.round(value * devicePixelRatio) / devicePixelRatio`), matching native `PixelRatio.roundToNearestPixel`. Two measurements that paint the same physical pixel now collapse to the same JS value, breaking the loop.
	- Files changed: `dist/recyclerview/utils/measureLayout.web.js` only.
	- Upstream PR/issue: TBD
	- E/App issue: https://github.com/Expensify/App/issues/91584
	- Sentry: https://expensify.sentry.io/issues/APP-DQ2
	- PR introducing patch: https://github.com/Expensify/App/pull/91799

App/patches/@shopify/flash-list/@shopify+flash-list+2.3.0+010+fix-web-subpixel-rounding.patch

Lines 8 to 13 in fec6b33

	export function roundOffPixel(value) {
	- return value;
	+ const dpr = typeof window !== "undefined" && window.devicePixelRatio
	+ ? window.devicePixelRatio
	+ : 1;
	+ return Math.round(value * dpr) / dpr;

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

Patch FlashList's web layout handling rather than changing the description save flow. First, make the web roundOffPixel() implementation snap measurements to the device-pixel grid so equivalent painted sizes collapse to the same JS value.

App/patches/@shopify/flash-list/@shopify+flash-list+2.3.0+010+fix-web-subpixel-rounding.patch

Lines 8 to 13 in fec6b33

	export function roundOffPixel(value) {
	- return value;
	+ const dpr = typeof window !== "undefined" && window.devicePixelRatio
	+ ? window.devicePixelRatio
	+ : 1;
	+ return Math.round(value * dpr) / dpr;

Then add a web-only guard in LinearLayoutManager.updateLayoutParams() for the remaining classic-scrollbar case. Keep a short history of rounded cross-axis sizes, detect the strict A,B,A,B ping-pong where the two values differ by no more than scrollbar width, and settle boundedSize to the smaller value that already accounts for the scrollbar. That breaks the feedback loop without treating a real window resize as oscillation.

App/patches/@shopify/flash-list/@shopify+flash-list+2.3.0+012+fix-scrollbar-oscillation-crash.patch

Lines 24 to 55 in fec6b33

	+ // --- Scrollbar oscillation guard (web only) ---
	+ // On web a vertical scrollbar appearing/disappearing changes the measured cross-axis size by
	+ // the scrollbar width. That feeds back into layout and toggles the scrollbar again, an
	+ // infinite layout loop that crashes the app. Native uses overlay scrollbars and never
	+ // oscillates, so this runs on web only.
	+ // We treat a change as scrollbar-induced only when ALL hold,
	+ // so a manual window resize is never misread:
	+ // (1) the last 4 rounded sizes strictly alternate between exactly two values (A,B,A,B),
	+ // (2) which is 3 consecutive flips — a drag never revisits the same two pixels that often,
	+ // (3) the two values differ by no more than a scrollbar's width.
	+ // When detected we settle on the smaller value (it already accounts for the scrollbar, so
	+ // items never overflow the client width).
	+ let nextBoundedSize = measuredBoundedSize;
	+ if (Platform.OS === "web") {
	+ const history = this.recentBoundedSizes ?? (this.recentBoundedSizes = []);
	+ history.push(Math.round(measuredBoundedSize));
	+ if (history.length > BOUNDED_SIZE_HISTORY_LENGTH) {
	+ history.shift();
	+ }
	+ if (history.length === BOUNDED_SIZE_HISTORY_LENGTH) {
	+ const [a, b, c, d] = history;
	+ const isScrollbarOscillation = a === c &&
	+ b === d &&
	+ a !== b &&
	+ Math.abs(a - b) <= SCROLLBAR_OSCILLATION_TOLERANCE;
	+ if (isScrollbarOscillation) {
	+ // Settle on the smaller of the two oscillating values.
	+ nextBoundedSize = Math.min(a, b);
	+ }
	+ }
	+ }
	+ this.boundedSize = nextBoundedSize;

This belongs in the shared FlashList patch layer because the crash is driven by list measurement feedback. A provider-only change would not stop a borderline report-action list from repeatedly toggling its scrollbar and re-laying out.

Test coverage:

• Add a small FlashList layout-manager regression test or package-patch fixture that feeds cross-axis sizes such as 375, 355, 375, 355 and verifies the bounded size settles, while a normal resize sequence does not.
• Add/keep coverage for the web roundOffPixel() helper so fractional values round by window.devicePixelRatio.
• Manually verify on Windows Chrome or another classic-scrollbar setup: open a report or transaction thread whose content height is close to the viewport height, update the description/category/tag/merchant or send a message so the list crosses the scroll boundary, and confirm no GenericErrorPage or maximum update depth console error occurs.
• Manually verify the original Search flow: Search for expenses, open a submit expense result, edit Description, Save, and confirm the app returns to search/view/:reportID with the report UI intact.

What alternative solutions did you explore? (Optional)

Moving the edit-message provider's render-time state setters into effects would make that provider safer, but it does not address the accepted crash path: FlashList can still re-enter layout when web scrollbar width or subpixel measurements keep changing. Clearing edit drafts or delaying Navigation.goBack(backTo) would only hide one trigger and could drop legitimate user draft state.

[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)