[Due for payment 2026-06-16] [$250] NewDot Desktop PWA crashes with React error #185 (infinite render loop) after sending a message in a thread

[melvin-bot]

Description

The NewDot desktop PWA (Chrome, macOS) crashed immediately after hitting Enter to send a message in a thread. The app's error boundary caught a Minified React error #185 — "Maximum update depth exceeded" — indicating an infinite setState/re-render loop was triggered by the new comment being inserted into the inverted FlashList (ReportActionsList).

The backend was healthy — the AddComment request returned 200 OK and the message was stored successfully. The crash is purely client-side.

---

Environment

Field	Value
App version	9.3.89-5
Platform	web — Chrome 148, macOS (desktop PWA)
Host	staging.new.expensify.com
accountID	4087621
Report / thread ID	3091454369606852

---

Steps to Reproduce

1. Open a thread (child report) in NewDot desktop PWA on staging (v9.3.89-5).
2. Type a message and press Enter to send.
3. Observe: app crashes to the error boundary screen immediately after sending.

---

Expected Result

Message sends and the thread's message list updates without crashing.

Actual Result

App crashes with Minified React error #185 — "Maximum update depth exceeded". The error boundary is triggered ~180ms after the message send.

---

Crash Details

Error: NewExpensify crash caught by error boundary — Minified React error #185

Timestamp (UTC): 2026-06-01 16:25:25.027

Timeline:

• 16:25:24.846 — AddComment sent to thread report 3091454369606852 (clientCreatedTime)
• 16:25:25.027 — Infinite render loop detected → error boundary fires → crash (~180ms later)
• 16:25:57 — User reloaded and re-sent the message successfully

Component stack (from crash log):

ViewHolderCollection
  → RecyclerViewComponent
    → FlashList / InvertedFlashList
      → ReportActionsList
        → ReportActionsView
          → ReportScreen

Backend status: AddComment → 200 OK, commitCount 35008726001, Pusher events + follow-up jobs queued normally. The crash was not caused by a backend failure.

Internal request IDs (for log search):

• Send request: a04f92fc0875ba4c-LAX
• Crash log flush: a04f9303af30ba4c-SEA

---

Notes

• After reloading, the user was able to send messages normally — suggesting this may be a transient or state-specific trigger rather than a 100% repro on every thread message send.
• The issue may be related to how ReportActionsList / InvertedFlashList handles list state updates when a new optimistic comment is inserted.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061488654292816928
• Upwork Job ID: 2061488654292816928
• Last Price Increase: 2026-06-01

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

@melvin-bot[bot] the AutoAssignerTriage label has been deprecated. Please use Bug for issue triage. See https://stackoverflowteams.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Issue Analysis

Root cause (confident): This is a client-side infinite render loop inside FlashList v2 (@shopify/flash-list@2.3.0), not a backend problem. The crash's component stack is entirely FlashList-internal (ViewHolderCollection → RecyclerViewComponent → FlashList), and React error #185 ("Maximum update depth exceeded") fires when a component repeatedly calls setState during commit/layout. Inserting the new optimistic comment into the inverted ReportActionsList pushes FlashList v2's RecyclerView into a re-measure → re-render loop. The 200 OK AddComment confirms the backend is irrelevant to the crash.

Most likely trigger (medium confidence, unproven): the maintainVisibleContentPosition (MVCP) configuration App hands FlashList v2. It's assembled from several sources that can change as a message is inserted, and FlashList v2 re-anchors whenever MVCP changes — a borderline scroll/marker state at send time can make that re-anchor recursive. The recent move to FlashList v2 (2.3.0, RecyclerView/new-arch) is the likely regression vector.

⚠️ I could not confirm the exact App-level trigger. I traced the two most obvious app-code loops and ruled both out (details below). The decisive next step is a source-mapped Sentry stack — the minified #185 only shows FlashList internals.

Investigation details — what was verified and ruled out

Hypotheses ruled out (with evidence):

1. onContentSizeChange → scroll-threshold loop — RULED OUT. ReportActionsList.tsx:965-967 calls trackVerticalScrolling(undefined). In useReportUnreadMessageScrollTracking.ts:86-110, the undefined arg skips onTrackScrolling, so it never touches hasScrolledOverThreshold (the value feeding MVCP at :375). The only setState it can hit (setIsFloatingMessageCounterVisible) is guarded/idempotent, so repeated calls don't oscillate.

2. Unread-marker useLayoutEffect oscillation — RULED OUT as a standalone loop. ReportActionsList.tsx:438-451 calls setUnreadMarkerTime, but its dep array is [lastAction?.created]. After one send, lastAction.created is stable, so the effect can't re-fire repeatedly. (The eslint-disable exhaustive-deps here and the render-phase ref write at line 323 are real smells, but not an infinite loop on their own.)

Remaining suspect (not proven): MVCP prop churn into FlashList v2. The MVCP value is built in three places that can shift on insert:

• ReportActionsList.tsx:957-962 — shouldMaintainVisibleContentPosition + a conditional {autoscrollToBottomThreshold…} object.
• InvertedFlashList/index.tsx:46-51 — merges two MVCP sources.
• useFlashListScrollKey.ts:50 — {disabled: …}.

Why thread-specific + transient: threads usually have no unread marker and a particular scroll/anchor state on send; the loop only ignites when that state lines up, which is why a reload (fresh state) let the user send normally.

Env confirmed: @shopify/flash-list is pinned at 2.3.0 (FlashList v2, RecyclerView — matches the ViewHolderCollection frames), no patches/ entry for it.

Possibly related: #91584 is another open React #185 ("Uh-oh") crash, but in the Search/expense-description flow, so likely a different root cause sharing the generic error code — not a duplicate.

Recommended next steps (in priority order):

1. Pull the source-mapped Sentry JS stack for error Add link styles for sidebar footer #185 at 2026-06-01 16:25:25Z (accountID 4087621, report 3091454369606852). This is the only thing that will pinpoint the exact setState in the loop. (App's Sentry skill / internal access required.)
2. Targeted repro: open a thread with no unread marker, scroll so the list is near the visibility threshold, then send — rather than expecting a 100% repro.
3. Mitigation to test: stabilize the MVCP props so FlashList v2 doesn't re-anchor recursively on insert, and check whether @shopify/flash-list@2.3.0 has a known inverted-list MVCP loop bug (upstream issues / version bump).

---

Next Steps for Contributor+ team:

• To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92263) — but note the exact fix isn't yet pinned down; the Sentry stack in step 1 should come first.
• To refine: @MelvinBot <your feedback> (e.g. paste the source-mapped stack and I'll narrow the loop).
• To reject: Explain why.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-01 16:54:00 UTC.

Replaces my earlier proposal. The earlier draft correctly focused on FlashList maintain-visible-content-position during a new message insert, but it missed the specific thread trigger: top-aligned thread reports keep MVCP enabled after the initial alignment handoff. This version narrows the fix to that persistent MVCP state plus the unstable MVCP prop objects.

Proposal

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

The desktop web/PWA thread view can crash with React error #185 immediately after sending a message. The AddComment request succeeds and the message is stored, but the client enters a render/update loop while the optimistic/new report action is inserted into the inverted FlashList.

What is the root cause of that problem?

The crash is caused by the thread list leaving FlashList's maintain-visible-content-position behavior active during a current-user live-tail insert, while Expensify's own send path is also forcing the same list back to the newest message.

When a message is sent, addActions() writes the optimistic report action into REPORT_ACTIONS and then calls notifyNewAction():

App/src/libs/actions/Report/index.ts

Lines 974 to 1078 in 1afa7b0

	const optimisticData: Array<
	OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS | typeof ONYXKEYS.PERSONAL_DETAILS_LIST | typeof ONYXKEYS.COLLECTION.SNAPSHOT>
	> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: optimisticReport,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: optimisticReportActions as ReportActions,
	},
	];
	// Initializing as an empty typed object to allow dynamic key assignment resolves TypeScript type inference issue
	const snapshotDataToStore: NullishDeep<SearchResultDataType> = {};
	snapshotDataToStore[`${ONYXKEYS.COLLECTION.REPORT}${reportID}`] = optimisticReport;
	snapshotDataToStore[`${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`] = optimisticReportActions;
	const optimisticSnapshotUpdate = buildOptimisticSnapshotData(CONST.SEARCH.DATA_TYPES.CHAT, snapshotDataToStore);
	// We are pushing the optimistic report and report actions into the chat snapshot so that the newly sent message appears immediately in "Reports > Chats" while offline.
	if (optimisticSnapshotUpdate) {
	optimisticData.push(optimisticSnapshotUpdate);
	}
	optimisticData.push(...getOptimisticDataForAncestors(ancestors, currentTime, CONST.RED_BRICK_ROAD_PENDING_ACTION.ADD));
	const successReportActions: OnyxCollection<NullishDeep<ReportAction>> = {};
	for (const [actionKey] of Object.entries(optimisticReportActions)) {
	successReportActions[actionKey] = {pendingAction: null, isOptimisticAction: null};
	}
	const successData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: successReportActions,
	},
	];
	let failureReport: Partial<Report> = {
	lastMessageText: '',
	lastVisibleActionCreated: '',
	};
	const {lastMessageText = ''} = ReportActionsUtils.getLastVisibleMessage(reportID);
	if (lastMessageText) {
	const lastVisibleActionCreated = lastVisibleAction?.created;
	failureReport = {
	lastMessageText,
	lastVisibleActionCreated,
	lastActorAccountID,
	};
	}
	const failureReportActions: Record<string, OptimisticAddCommentReportAction | ReportAction | null> = {};
	for (const [actionKey, action] of Object.entries(optimisticReportActions)) {
	failureReportActions[actionKey] = {
	...(action as OptimisticAddCommentReportAction),
	errors: getMicroSecondOnyxErrorWithTranslationKey('report.genericAddCommentFailureMessage'),
	};
	}
	// In case of error bring back the follow up buttons to the cast comment
	if (lastActorAccountID === CONST.ACCOUNT_ID.CONCIERGE && lastActionReportActionID) {
	failureReportActions[lastActionReportActionID] = lastVisibleAction;
	}
	// In case of error, remove the optimistic Concierge response
	if (pregeneratedResponseParams) {
	failureReportActions[pregeneratedResponseParams.optimisticConciergeReportActionID] = null;
	}
	const failureData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT | typeof ONYXKEYS.COLLECTION.REPORT_ACTIONS>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: failureReport,
	},
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT_ACTIONS}${reportID}`,
	value: failureReportActions as ReportActions,
	},
	];
	// Update the timezone if it's been 5 minutes from the last time the user added a comment
	if (DateUtils.canUpdateTimezone() && currentUserAccountID) {
	const timezone = DateUtils.getCurrentTimezone(timezoneParam);
	parameters.timezone = JSON.stringify(timezone);
	optimisticData.push({
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.PERSONAL_DETAILS_LIST,
	value: {[currentUserAccountID]: {timezone}},
	});
	DateUtils.setTimezoneUpdated();
	}
	API.write(commandName, parameters, {
	optimisticData,
	successData,
	failureData,
	});
	notifyNewAction(resolvedNotifyReportID, lastAction, lastAction?.actorAccountID === currentUserAccountID);

That notification drives useReportActionsNewActionLiveTail(), which calls scrollToBottom() and sets isScrollToBottomEnabled so ReportActionsList scrolls again after the next layout:

App/src/pages/inbox/report/useReportActionsNewActionLiveTail.ts

Lines 78 to 129 in 1afa7b0

	const scrollToBottomForCurrentUserAction = useEffectEvent((isFromCurrentUser: boolean, action?: OnyxTypes.ReportAction) => {
	InteractionManager.runAfterInteractions(() => {
	// If a new comment is added and it's from the current user scroll to the bottom otherwise leave the user positioned where
	// they are now in the list.
	if (!isFromCurrentUser || (!isReportTopmostSplitNavigator() && !Navigation.getReportRHPActiveRoute())) {
	return;
	}
	if (!hasNewestReportAction && !isFromCurrentUser) {
	if (Navigation.getReportRHPActiveRoute()) {
	return;
	}
	Navigation.setNavigationActionToMicrotaskQueue(() => {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(reportID));
	});
	return;
	}
	const shouldJumpToLiveTail =
	!isOffline && action?.actionName !== CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW && (hasNewerActions || !!linkedReportActionID || unreadMarkerReportActionID);
	if (shouldJumpToLiveTail) {
	if (liveTailJumpRef.current.stage === 'idle') {
	liveTailJumpRef.current = {stage: 'open_report'};
	openReport({
	reportID,
	introSelected,
	betas,
	});
	}
	return;
	}
	const index = sortedVisibleReportActions.findIndex((item) => item.reportActionID === action?.reportActionID);
	if (action?.actionName === CONST.REPORT.ACTIONS.TYPE.REPORT_PREVIEW) {
	if (index > 0) {
	setTimeout(() => {
	reportScrollManager.scrollToIndex(index);
	}, 100);
	} else {
	setIsFloatingMessageCounterVisible(false);
	reportScrollManager.scrollToBottom();
	}
	if (action?.reportActionID) {
	setActionIdToHighlight(action.reportActionID);
	}
	} else {
	setIsFloatingMessageCounterVisible(false);
	reportScrollManager.scrollToBottom();
	}
	setIsScrollToBottomEnabled(true);
	});

At the same time, normal thread reports are top-aligned by this logic in ReportActionsList:

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

Lines 325 to 375 in 1afa7b0

	const isTransactionThreadReport = useMemo(() => isTransactionThread(parentReportAction) && !isSentMoneyReportAction(parentReportAction), [parentReportAction]);
	const isMoneyRequestOrInvoiceReport = useMemo(() => isMoneyRequestReport(report) || isInvoiceReport(report), [report]);
	const shouldBeAlignedToTop = useMemo(() => isTransactionThreadReport || isMoneyRequestOrInvoiceReport, [isMoneyRequestOrInvoiceReport, isTransactionThreadReport]);
	const initialScrollKey = useMemo(() => {
	const actionID = linkedReportActionID ?? unreadMarkerReportActionID;
	if (!actionID) {
	return;
	}
	// The correct scroll behavior in this case will be handled by shouldFocusToTopOnMount logic
	if (shouldBeAlignedToTop && sortedVisibleReportActionsObjects[actionID]?.actionName === CONST.REPORT.ACTIONS.TYPE.CREATED) {
	return;
	}
	return actionID;
	}, [linkedReportActionID, unreadMarkerReportActionID, shouldBeAlignedToTop, sortedVisibleReportActionsObjects]);
	const shouldFocusToTopOnMount = shouldBeAlignedToTop && !initialScrollKey;
	const [shouldAutoscrollToBottom, setShouldAutoscrollToBottom] = useState(shouldFocusToTopOnMount);
	const renderedVisibleReportActions = useMemo(() => {
	if (!draftReportAction) {
	return sortedVisibleReportActions;
	}
	// Insert the synthetic draft into the already-descending render list without treating it as a persisted report action.
	for (const [index, action] of sortedVisibleReportActions.entries()) {
	if (action.reportActionID === draftReportAction.reportActionID) {
	if (!isDraftPendingCompletion) {
	return sortedVisibleReportActions;
	}
	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
	visibleReportActionsWithDraft[index] = draftReportAction;
	return visibleReportActionsWithDraft;
	}
	if (isNewerReportAction(draftReportAction, action)) {
	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
	visibleReportActionsWithDraft.splice(index, 0, draftReportAction);
	return visibleReportActionsWithDraft;
	}
	}
	const visibleReportActionsWithDraft = [...sortedVisibleReportActions];
	visibleReportActionsWithDraft.push(draftReportAction);
	return visibleReportActionsWithDraft;
	}, [draftReportAction, isDraftPendingCompletion, sortedVisibleReportActions]);
	const draftMessageHTML = draftReportAction ? getReportActionMessage(draftReportAction)?.html : undefined;
	const isSyntheticDraftVisible = !!draftReportAction && renderedVisibleReportActions !== sortedVisibleReportActions;
	const draftAutoScrollKey = isSyntheticDraftVisible ? `${draftReportAction.reportActionID}:${draftMessageHTML ?? ''}` : '';
	const previousDraftAutoScrollKey = usePrevious(draftAutoScrollKey);
	const [hasScrolledOverThreshold, setHasScrolledOverThreshold] = useState(() => scrollOffsetRef.current > CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD);
	const shouldMaintainVisibleContentPosition = hasScrolledOverThreshold || shouldFocusToTopOnMount;

shouldFocusToTopOnMount is true for transaction threads without a deep-link/unread initial key, and shouldMaintainVisibleContentPosition includes that value directly. The initial autoscroll flag is later turned off by onLoad / the follow-up effect:

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

Lines 889 to 912 in 1afa7b0

	// Data is ready at the moment FlashList finishes its first render.
	// Wait one frame so the initial autoscroll-to-top can settle, then disable it.
	const onLoad = () => {
	if (!shouldFocusToTopOnMount) {
	return;
	}
	if (!reportLoadingState?.hasOnceLoadedReportActions && !isOffline) {
	return;
	}
	requestAnimationFrame(() => setShouldAutoscrollToBottom(false));
	};
	const prevHasOnceLoadedReportActions = usePrevious(reportLoadingState?.hasOnceLoadedReportActions);
	// Data finished initial loading after the list mounted. onLoad has already fired, so we need
	// a separate trigger to turn off autoscroll-to-top.
	useEffect(() => {
	if (!shouldFocusToTopOnMount || !shouldAutoscrollToBottom) {
	return;
	}
	if (prevHasOnceLoadedReportActions || !reportLoadingState?.hasOnceLoadedReportActions) {
	return;
	}
	requestAnimationFrame(() => setShouldAutoscrollToBottom(false));
	}, [shouldFocusToTopOnMount, shouldAutoscrollToBottom, prevHasOnceLoadedReportActions, reportLoadingState?.hasOnceLoadedReportActions]);

but shouldFocusToTopOnMount itself stays true for the lifetime of that thread screen. So after the initial mount has settled, FlashList MVCP is still enabled even when the user is at the live tail and sends their own message.

The wrapper also gives FlashList a fresh MVCP object on every render:

App/src/components/FlashList/useFlashListScrollKey.ts

Lines 21 to 63 in 1afa7b0

	export default function useFlashListScrollKey<T>({data, keyExtractor, initialScrollKey, onStartReached, shouldMaintainVisibleContentPosition}: FlashListScrollKeyProps<T>) {
	const [isInitialRender, setIsInitialRender] = useState(!!initialScrollKey);
	const [hasLinkingSettled, setHasLinkingSettled] = useState(!initialScrollKey);
	// Two-frame handoff for deep-link:
	// RAF 1: switch from sliced data to the full array — FlashList's default MVCP pins the
	// linked item through the data swap.
	// RAF 2: pinning has happened, disable MVCP so it doesn't cause later jumps.
	useEffect(() => {
	if (!isInitialRender) {
	return;
	}
	// Without an anchor on this frame, we are not doing the deep-link slice handoff; clear the flag so a key that
	// appears later (e.g. marking a message unread) cannot reuse the "first paint" slice path.
	if (!initialScrollKey) {
	// If the initial scroll key gets unset, we need to disable the initial render flag,
	// otherwise the list will not render..
	// eslint-disable-next-line react-hooks/set-state-in-effect
	setIsInitialRender(false);
	return;
	}
	requestAnimationFrame(() => {
	setIsInitialRender(false);
	requestAnimationFrame(() => setHasLinkingSettled(true));
	});
	}, [isInitialRender, initialScrollKey]);
	const maintainVisibleContentPosition: FlashListProps<T>['maintainVisibleContentPosition'] = {disabled: !shouldMaintainVisibleContentPosition && hasLinkingSettled};
	if (!isInitialRender || !initialScrollKey) {
	return {displayedData: data, onStartReached, maintainVisibleContentPosition};
	}
	const targetIndex = data.findIndex((item, index) => keyExtractor(item, index) === initialScrollKey);
	if (targetIndex <= 0) {
	return {displayedData: data, onStartReached, maintainVisibleContentPosition};
	}
	// On the first render, slice from the target onward so the target item
	// appears at the visual bottom of the inverted list — no scrolling needed.
	return {displayedData: data.slice(targetIndex), onStartReached: () => {}, maintainVisibleContentPosition};

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

Lines 46 to 61 in 1afa7b0

	const maintainVisibleContentPosition = maintainVisibleContentPositionProp
	? {
	...maintainVisibleContentPositionForScrollKey,
	...maintainVisibleContentPositionProp,
	}
	: maintainVisibleContentPositionForScrollKey;
	return (
	<FlashList<T>
	{...restProps}
	inverted
	onStartReached={onStartReached}
	data={displayedData}
	keyExtractor={keyExtractor}
	CellRendererComponent={CellRendererComponent}
	maintainVisibleContentPosition={maintainVisibleContentPosition}

During the optimistic insert, FlashList v2 tries to preserve the old visible cell and correct offsets, while our live-tail code is simultaneously scrolling the inverted list to index 0. That offset-correction/scroll/layout cycle is why the React stack ends in ViewHolderCollection -> RecyclerViewComponent -> FlashList / InvertedFlashList -> ReportActionsList, and why the backend can succeed while the PWA crashes.

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

Make MVCP stable, and only enable it for the states where we actually want FlashList to preserve the old visible item.

Concretely:

1. In src/components/FlashList/useFlashListScrollKey.ts, memoize the returned maintainVisibleContentPosition object so its identity only changes when shouldMaintainVisibleContentPosition or hasLinkingSettled changes.
2. In src/components/FlashList/InvertedFlashList/index.tsx, memoize the merged MVCP object instead of spreading a new object every render.
3. In src/pages/inbox/report/ReportActionsList.tsx, separate initial thread top-alignment from ongoing MVCP. Keep MVCP enabled while the initial shouldAutoscrollToBottom/top-alignment handoff is still settling, and keep it enabled when the user has scrolled away from the live tail. Once the initial handoff is done and the user is at the live tail, do not keep MVCP enabled solely because shouldFocusToTopOnMount is true.
4. Also suppress MVCP while a current-user live-tail scroll is pending via isScrollToBottomEnabled, because in that path Expensify intentionally scrolls to the newest action and FlashList should not preserve the previous visible cell at the same time.

That preserves MVCP for the important cases: deep-link/unread handoff, initial thread alignment, pagination, and users reading older messages while new actions arrive. It removes MVCP from the current-user send-at-live-tail path that is producing the loop.

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

• A web transaction-thread report with no initial scroll key: after the initial load handoff completes, MVCP should no longer remain enabled just because shouldFocusToTopOnMount is true.
• A current-user optimistic comment inserted while the thread is at the live tail: the list should update and scroll to the newest action without repeatedly toggling MVCP or throwing.
• A user scrolled up in the same thread: inserting another action should keep MVCP enabled so the visible reading position is preserved.
• A deep-linked or unread report open: the existing two-frame initialScrollKey handoff should still preserve the linked/unread item and then settle.

What alternative solutions did you explore? (Optional)

I checked the send/API path, but the issue already shows AddComment returns 200 and the message persists. Changing retry behavior or backend handling would not fix the client-side render loop.

I also checked the edit-message draft provider because it has known render-time state writes, but sending a new thread comment does not require an edit draft. The direct trigger here is the optimistic REPORT_ACTIONS insert plus the ReportActionsList/FlashList MVCP scroll collision.

[melvin-bot]

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

[melvin-bot]

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

[wildan-m]

Proposal

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

Sending a message in a thread can crash NewDot with Minified React error #185 ("Maximum update depth exceeded"). The newly inserted optimistic comment triggers an infinite re-render loop inside the inverted list (ReportActionsList → InvertedFlashList → FlashList), and the error boundary fires ~180ms after send. The crash is purely client-side (the AddComment request succeeds), and it is intermittent — it depends on the resting scroll position at the moment the message is inserted.

What is the root cause of that problem?

ReportActionsList drives the list's maintainVisibleContentPosition (MVCP) on/off state from a piece of React state, hasScrolledOverThreshold, that is itself updated on every scroll event. This creates a feedback loop.

hasScrolledOverThreshold is recomputed on each scroll and feeds shouldMaintainVisibleContentPosition:

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

Lines 374 to 375 in 1afa7b0

	const [hasScrolledOverThreshold, setHasScrolledOverThreshold] = useState(() => scrollOffsetRef.current > CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD);
	const shouldMaintainVisibleContentPosition = hasScrolledOverThreshold || shouldFocusToTopOnMount;

It is flipped from the scroll handler whenever the offset crosses ACTION_VISIBLE_THRESHOLD (250px):

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

Lines 473 to 478 in 1afa7b0

	onTrackScrolling: (event: NativeSyntheticEvent<NativeScrollEvent>) => {
	const offset = event.nativeEvent.contentOffset.y;
	scrollOffsetRef.current = offset;
	setHasScrolledOverThreshold(offset > CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD);
	onScroll?.(event);
	},

shouldMaintainVisibleContentPosition is then passed straight into the inverted list, where it toggles maintainVisibleContentPosition.disabled:

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

Lines 957 to 962 in 1afa7b0

	shouldMaintainVisibleContentPosition={shouldMaintainVisibleContentPosition}
	initialScrollIndex={shouldFocusToTopOnMount ? renderedVisibleReportActions.length - 1 : undefined}
	initialScrollIndexParams={shouldFocusToTopOnMount ? {viewOffset: windowHeight} : undefined}
	maintainVisibleContentPosition={
	shouldAutoscrollToBottom ? {autoscrollToBottomThreshold: CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD, animateAutoScrollToBottom: false} : undefined
	}

The loop: sending a message inserts an optimistic comment, the list's content size grows, and FlashList programmatically adjusts the inverted scroll offset to maintain position. That adjustment emits a scroll event, which re-evaluates offset > 250 and flips hasScrolledOverThreshold. Flipping it flips shouldMaintainVisibleContentPosition, which re-toggles MVCP on the list, which again perturbs the scroll offset across the 250px boundary — emitting another scroll event, and so on. When the resting offset happens to sit near the threshold (common in a short thread right after sending), the toggle never settles and React aborts with error #185. Because it only runs away when the offset lands near the boundary, the crash is intermittent rather than 100% reproducible, exactly as reported.

This single-threshold coupling between the per-scroll state and the MVCP-enable decision was introduced relatively recently (the hasScrolledOverThreshold → shouldMaintainVisibleContentPosition wiring), which is consistent with this being a regression on v9.3.89.

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

Break the scroll → state → MVCP feedback loop so that toggling maintainVisibleContentPosition cannot, by itself, flip the very state that controls it.

The cleanest way is to add hysteresis (a dead band) to the hasScrolledOverThreshold transition instead of using a single 250px boundary for both directions:

• Set hasScrolledOverThreshold to true when the offset rises above ACTION_VISIBLE_THRESHOLD (250px), as today.
• Only clear it back to false when the offset falls clearly below the threshold (e.g. below a lower exit bound such as 250 minus a small margin), rather than at the same 250px line.

Concretely, update the setter in the scroll handler to compare against the previous value and only flip when the offset is unambiguously on one side of the band, so a small MVCP-induced offset adjustment near 250px can no longer re-toggle the flag. This preserves the existing intent (keep the user's position when they have scrolled up, autoscroll when they are near the bottom) while guaranteeing the offset perturbation caused by enabling/disabling MVCP can no longer oscillate the state and re-render endlessly.

An equally valid alternative is to stop deriving the MVCP-enable decision from re-rendering state altogether: track the "scrolled over threshold" status in a ref and recompute shouldMaintainVisibleContentPosition only on genuine user-initiated scrolls, ignoring the programmatic scroll adjustments that MVCP itself triggers during content insertion.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/92263-mvcp-threshold-hysteresis?expand=1

What alternative solutions did you explore? (Optional)

Guarding the scroll handler to ignore scroll events that occur during a content-size change (i.e. suppress hasScrolledOverThreshold updates while a new action is being inserted), so that only deliberate user scrolling can change the MVCP state. This also breaks the loop but is more invasive than the hysteresis approach, since it requires coordinating the onContentSizeChange and scroll handlers.

[aswin-s]

Proposal

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

When a user sends a message in a thread on NewDot desktop PWA (Web/Chrome), the optimistic comment insertion into the inverted ReportActionsList triggers an infinite render loop and the app crashes with Minified React error #185 ("Maximum update depth exceeded") ~180ms after send. The backend AddComment succeeds; the crash is purely client-side. Expected: the comment appears in the thread and the list updates without crashing.

What is the root cause of that problem?

In src/components/FlashList/useFlashListScrollKey.ts:50, the hook unconditionally constructs a fresh maintainVisibleContentPosition: {disabled: ...} object on every render and returns it (lines 53/58/63). In src/components/FlashList/InvertedFlashList/index.tsx:46-51, when a caller also passes maintainVisibleContentPositionProp, a new merged object is spread on every render too. The maintainVisibleContentPosition prop reaching FlashList therefore has a new identity each render. When the optimistic comment is prepended to the inverted list, the react-native-web MVCP path (see patches/react-native-web/react-native-web+0.21.2+005+osr-improvement.patch) compares prevFirstVisibleItemKey/newFirstVisibleItemKey and calls setState based on this prop; because the prop reference keeps changing, the update never stabilizes and the component re-renders until React aborts at depth 50. This regressed in PR #88321, which introduced the always-on maintainVisibleContentPosition return value.

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

1. src/components/FlashList/useFlashListScrollKey.ts:50 — wrap the returned maintainVisibleContentPosition in useMemo keyed on [shouldMaintainVisibleContentPosition, hasLinkingSettled] so its identity is stable across renders that don't change those inputs.
2. src/components/FlashList/useFlashListScrollKey.ts:21-63 — when neither initialScrollKey nor shouldMaintainVisibleContentPosition is set (the steady-state thread case), return undefined for maintainVisibleContentPosition so callers passing only maintainVisibleContentPositionProp get a stable prop instead of a synthesized {disabled: true} object.
3. src/components/FlashList/InvertedFlashList/index.tsx:46-51 — memoize the merged maintainVisibleContentPosition with useMemo keyed on [maintainVisibleContentPositionProp, maintainVisibleContentPositionForScrollKey] so the spread does not create a new object on every render.
4. Verify by sending a message in a thread on Web; confirm no error boundary fires and that deep-link scroll behavior (the original PR [CP Staging] Fix maintainVisibleContentPosition behaviour after migration to FlashList #88321 feature) still works.

What alternative solutions did you explore? (Optional)

Reverting PR #88321 fixes the crash but reintroduces the deep-link scroll regression it solved; identity-stabilizing the prop preserves both behaviors.