[$250] Crash: Invariant Violation in VirtualizedList._createRenderMask in ReportActionsList on iOS

[mountiny]

Description

A recurring crash is occurring on iOS in the ReportActionsList component. VirtualizedList._createRenderMask receives an invalid cell range [0, -4] (negative end index), causing an invariant violation.

Sentry issue: https://expensify.sentry.io/issues/APP-6DB
Example event: https://expensify.sentry.io/issues/7290255649/events/6ea8f8a9ccb5478a875afbf95576a8d9/

Impact:

• 40,334 occurrences since first seen (2026-02-25)
• 18,801 users impacted
• Still ongoing as of 2026-05-18
• Affects HybridApp iOS builds (new.expensify@9.3.61-4)

Error

Invariant Violation: Invalid cells around viewport "[0, -4]" was passed to VirtualizedList._createRenderMask

Component Stack

VirtualizedList
  FlatList
    CustomFlatList
      BaseFlatListWithScrollKey
        FlatListWithScrollKey
          MoneyRequestReportActionsList
            ReportActionsList
              ReportScreen

Analysis

The [0, -4] value suggests that VirtualizedList is being passed props that result in a negative cell index being computed for the viewport render mask. The most likely causes are:

• An invalid or negative initialScrollIndex prop being passed to the FlatList in MoneyRequestReportActionsList or ReportActionsList
• A race condition where the list data changes (shrinks) while an initial scroll offset computed from a larger dataset is still being applied
• The getItemCount or item layout calculations returning values inconsistent with the actual data length

Steps to Investigate

1. Review MoneyRequestReportActionsList and ReportActionsList for how initialScrollIndex is calculated and whether it can ever produce a value larger than the current item count
2. Check if there is any case where the item list shrinks between when the scroll index is computed and when the list renders
3. Verify that getItemLayout (if used) returns consistent values with the data array length
4. Add a guard to clamp initialScrollIndex to Math.max(0, Math.min(index, data.length - 1)) as a defensive fix

Environment

• Platform: iOS (HybridApp)
• Device: iPhone14,6 (iPhone SE 3rd gen)
• OS: iOS 26.4.2
• Release: new.expensify@9.3.61-4
• Build type: hybrid_app

Issue Owner

Current Issue Owner: @WojtekBoman

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022056337409756110816
• Upwork Job ID: 2056337409756110816
• Last Price Increase: 2026-05-18

[MelvinBot]

Proposal

What is the root cause of that problem?

On iOS, useSafeAreaFrame returns { height: 0 } before the view has been measured in the layout pass. MoneyRequestReportActionsList.tsx:648 computes initialNumToRender from windowHeight:

availableHeight = 0 - (65 + 72) = -137
numToRender = Math.ceil(-137 / 35) = -3

Since -3 is truthy, the guard numToRender || undefined on line 653 does not trigger, so -3 is passed to FlatList as initialNumToRender.

React Native's initialNumToRenderOrDefault() only defaults for null/undefined, so -3 passes through. VirtualizedList._initialRenderRegion() then computes lastCellIndex = Math.min(itemCount, 0 + (-3)) - 1 = -4, producing cellsAroundViewport = {first: 0, last: -4} — the exact crash.

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

Clamp numToRender to a minimum of 1 in MoneyRequestReportActionsList.tsx:649:

- const numToRender = Math.ceil(availableHeight / minimumReportActionHeight);
+ const numToRender = Math.max(1, Math.ceil(availableHeight / minimumReportActionHeight));

This ensures initialNumToRender is always at least 1, which is safe for VirtualizedList and still optimal once windowHeight is measured on the next render.

What alternative solutions did you explore? (Optional)

1. Return undefined when windowHeight === 0: Would work but is less explicit. Using Math.max(1, ...) communicates intent clearly and handles any edge case where the subtraction exceeds windowHeight.
2. Guard at the FlatList wrapper level: More invasive and doesn't fix the root cause — the computation itself should never produce a negative value.

Investigation details

Data flow:

1. useWindowDimensions calls useSafeAreaFrame() → returns height: 0 before iOS layout
2. MoneyRequestReportActionsList.tsx:648 computes availableHeight = 0 - 137 = -137
3. Math.ceil(-137 / 35) = -3 → passed as initialNumToRender
4. On the linkedReportActionID path, getInitialNumToRender on native is a passthrough (returns the value as-is), so -3 still gets through
5. VirtualizedList._initialRenderRegion() → lastCellIndex = -4 → invariant violation: [0, -4]

Why iOS HybridApp specifically: useSafeAreaFrame relies on native layout measurement. In HybridApp iOS builds, the view hierarchy involves an OldDot→NewDot transition that may delay the initial layout pass, making the height: 0 window more likely to coincide with MoneyRequestReportActionsList mounting.

Impact: 40K+ occurrences, 18K+ users. The fix is a one-line clamp with no behavioral change once layout is measured.

---

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 iOS HybridApp builds, opening a money request report can crash inside React Native's VirtualizedList._createRenderMask with an invalid viewport range such as [0, -4].

What is the root cause of that problem?

MoneyRequestReportActionsList computes initialNumToRender from the current viewport height:

• App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

  Lines 641 to 654 in eaaffe3

  	const {windowHeight} = useWindowDimensions();
  	/**
  	* Calculates the ideal number of report actions to render in the first render, based on the screen height and on
  	* the height of the smallest report action possible.
  	*/
  	const initialNumToRender = useMemo((): number | undefined => {
  	const minimumReportActionHeight = styles.chatItem.paddingTop + styles.chatItem.paddingBottom + variables.fontSizeNormalHeight;
  	const availableHeight = windowHeight - (CONST.CHAT_FOOTER_MIN_HEIGHT + variables.contentHeaderHeight);
  	const numToRender = Math.ceil(availableHeight / minimumReportActionHeight);
  	if (linkedReportActionID) {
  	return getInitialNumToRender(numToRender);
  	}
  	return numToRender || undefined;
  	}, [styles.chatItem.paddingBottom, styles.chatItem.paddingTop, windowHeight, linkedReportActionID]);

That calculation subtracts the fixed chat footer/header heights from windowHeight, then does Math.ceil(availableHeight / minimumReportActionHeight). On small or transient iOS layouts, especially in HybridApp while the screen is being measured, availableHeight can be negative. When a linked report action is present, the native implementation of getInitialNumToRender returns that negative value unchanged:

• App/src/pages/inbox/report/getInitialNumReportActionsToRender/index.native.ts

  Lines 1 to 3 in eaaffe3

  	function getInitialNumToRender(numToRender: number): number {
  	return numToRender;
  	}

The money-request list then passes the negative value to FlatListWithScrollKey as initialNumToRender:

• App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

  Lines 706 to 746 in eaaffe3

  	initialNumToRender={initialNumToRender}
  	accessibilityLabel={translate('sidebarScreen.listOfChatMessages')}
  	testID="money-request-report-actions-list"
  	style={styles.overscrollBehaviorContain}
  	data={visibleReportActions}
  	renderItem={renderItem}
  	onViewableItemsChanged={onViewableItemsChanged}
  	keyExtractor={keyExtractor}
  	onLayout={recordTimeToMeasureItemLayout}
  	onEndReached={onEndReached}
  	onEndReachedThreshold={0.75}
  	onStartReached={onStartReached}
  	onStartReachedThreshold={0.75}
  	ListHeaderComponent={
  	<>
  	<MoneyRequestViewReportFields
  	report={report}
  	policy={policy}
  	/>
  	<MoneyRequestReportTransactionList
  	report={report}
  	onLayout={onLayout}
  	transactions={transactions}
  	newTransactions={newTransactions}
  	hasPendingDeletionTransaction={hasPendingDeletionTransaction}
  	reportActions={reportActions}
  	scrollToNewTransaction={scrollToNewTransaction}
  	policy={policy}
  	hasComments={visibleReportActions.length > 0}
  	isLoadingInitialReportActions={showReportActionsLoadingState}
  	/>
  	</>
  	}
  	keyboardShouldPersistTaps="handled"
  	onScroll={trackVerticalScrolling}
  	contentContainerStyle={[shouldUseNarrowLayout ? styles.pt4 : styles.pt3]}
  	ref={reportScrollManager.ref}
  	ListEmptyComponent={!isOffline && showReportActionsLoadingState ? <ReportActionsListLoadingSkeleton reasonAttributes={skeletonReasonAttributes} /> : undefined} // This skeleton component is only used for loading state, the empty state is handled by SearchMoneyRequestReportEmptyState
  	removeClippedSubviews={false}
  	initialScrollKey={linkedReportActionID}
  	/>

React Native uses initialNumToRender to build the initial render region. A value like -3 produces last = -4, which matches the Sentry invariant Invalid cells around viewport "[0, -4]".

The nearby regular report list has the same viewport-derived numToRender pattern before delegating to getReportActionsListInitialNumToRender:

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

  Lines 704 to 724 in eaaffe3

  	* Calculates the ideal number of report actions to render in the first render, based on the screen height and on
  	* the height of the smallest report action possible.
  	*/
  	const initialNumToRender = useMemo((): number => {
  	const minimumReportActionHeight = styles.chatItem.paddingTop + styles.chatItem.paddingBottom + variables.fontSizeNormalHeight;
  	const availableHeight = windowHeight - (CONST.CHAT_FOOTER_MIN_HEIGHT + variables.contentHeaderHeight);
  	const numToRender = Math.ceil(availableHeight / minimumReportActionHeight);
  	return getReportActionsListInitialNumToRender({
  	numToRender,
  	initialScrollKey,
  	shouldScrollToEndAfterLayout,
  	hasCreatedActionAdded,
  	sortedVisibleReportActionsLength: renderedVisibleReportActions.length,
  	isOffline,
  	getInitialNumToRender,
  	});
  	}, [
  	styles.chatItem.paddingBottom,
  	styles.chatItem.paddingTop,
  	windowHeight,
  	initialScrollKey,

• App/src/pages/inbox/report/getReportActionsListInitialNumToRender.ts

  Lines 20 to 28 in eaaffe3

  	if (shouldScrollToEndAfterLayout && (!hasCreatedActionAdded || isOffline)) {
  	return sortedVisibleReportActionsLength;
  	}
  	if (initialScrollKey) {
  	return getInitialNumToRender(numToRender);
  	}
  	return numToRender;

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

Clamp the viewport-derived render count before any report actions list passes it to a native virtualized list.

Concretely:

1. Add a small helper near the report action render-count logic, for example getSafeInitialNumToRender(numToRender), that returns at least 1 for finite numbers and falls back to 1 for invalid values.
2. Use that helper in MoneyRequestReportActionsList before calling native getInitialNumToRender(numToRender) and before returning the non-linked numToRender branch.
3. Apply the same guard in getReportActionsListInitialNumToRender or at its call site so ReportActionsList cannot pass a negative value through the shared helper path either.
4. Keep the existing web behavior that enforces a larger minimum batch size. The guard should only prevent invalid values; it should not change the current web minimum of 50 or the existing scroll-key behavior.

This keeps the fix local to the list render-count calculation instead of changing React Native, FlatListWithScrollKey, or scroll-key pagination behavior.

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

Add unit coverage for the render-count helper/shared calculation:

• When numToRender is negative and there is a linked report action, the result is clamped to a positive value before native getInitialNumToRender can receive it.
• When numToRender is negative and there is no linked report action, the returned initialNumToRender is still positive.
• Existing positive values continue to return the same platform-adjusted values as today.
• The scroll-to-end branch still returns the full list length when that branch applies.

[melvin-bot]

Current assignee @shubham1206agra is eligible for the External assigner, not assigning anyone new.

[dilshodmackbook-sketch]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-18 11:37:04 UTC.

Proposal

What is the root cause of that problem?

initialNumToRender passed to the underlying FlatList/VirtualizedList becomes negative for MoneyRequestReportActionsList, which is the only consumer in the crashing stack that uses FlatListWithScrollKey (the others use FlashList).

It's computed from window height here:

https://github.com/Expensify/App/blob/main/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx#L658-L666

const minimumReportActionHeight = styles.chatItem.paddingTop + styles.chatItem.paddingBottom + variables.fontSizeNormalHeight; // 8 + 8 + 20 = 36
const availableHeight = windowHeight - (CONST.CHAT_FOOTER_MIN_HEIGHT + variables.contentHeaderHeight); // windowHeight - 137
const numToRender = Math.ceil(availableHeight / minimumReportActionHeight);

When windowHeight < 137 (transient on iOS during HybridApp transitions, split‑view, backgrounding, orientation changes), availableHeight is negative and numToRender becomes negative. The numToRender || undefined guard only filters 0, not negative values.

Inside React Native, VirtualizedList._initialRenderRegion then computes:

const firstCellIndex = Math.max(0, Math.min(itemCount - 1, Math.floor(initialScrollIndex ?? 0))); // = 0
const lastCellIndex  = Math.min(itemCount, firstCellIndex + initialNumToRender) - 1;              // negative

With numToRender = -3 we get lastCellIndex = -4, producing cellsAroundViewport = {first: 0, last: -4}. That fails the invariant in _createRenderMask (last >= first - 1), giving the exact "[0, -4]" from Sentry:

Invalid cells around viewport "[0, -4]" was passed to VirtualizedList._createRenderMask

This crash is iOS‑only (matching Sentry) because the web MVCPFlatList wrapper already clamps the prop on web — Math.max(0, initialNumToRender ?? 0) || undefined at https://github.com/Expensify/App/blob/main/src/components/FlatList/FlatList/index.tsx#L261 — but CustomFlatList for index.ios.tsx and index.android.tsx (and BaseFlatListWithScrollKey) forward the prop unchanged. The same unsafe numToRender lives in ReportActionsList, but it feeds InvertedFlashList, so it doesn't hit this invariant.

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

I'd clamp numToRender at the source so a transient zero/tiny windowHeight can't produce a negative value:

-        const numToRender = Math.ceil(availableHeight / minimumReportActionHeight);
+        const numToRender = Math.max(0, Math.ceil(availableHeight / minimumReportActionHeight));
         if (linkedReportActionID) {
             return getInitialNumToRender(numToRender);
         }
         return numToRender || undefined;

As defense in depth so any future caller can't reintroduce the same crash, I'd also clamp inside BaseFlatListWithScrollKey before forwarding to FlatList — mirroring the existing web wrapper:

-            initialNumToRender={initialNumToRender}
+            initialNumToRender={initialNumToRender != null ? Math.max(0, initialNumToRender) || undefined : undefined}

(in https://github.com/Expensify/App/blob/main/src/components/FlatList/FlatListWithScrollKey/BaseFlatListWithScrollKey.tsx#L52-L88)

For consistency I'd apply the same Math.max(0, …) to the identical calculation in ReportActionsList at https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionsList.tsx#L709-L731 — it doesn't crash today (FlashList doesn't use _createRenderMask), but a negative initialNumToRender still produces wrong StaticReportActionsPreview slicing at https://github.com/Expensify/App/blob/main/src/pages/inbox/report/ReportActionsList.tsx#L911 (slice(-initialNumToRender ? ... : 0) would slice from the end with a positive value when the intent was zero).

What alternative solutions did you explore? (Optional)

• Clamp only inside _initialRenderRegion‑adjacent state via onScrollToIndexFailed / defensive index math (Math.max(0, Math.min(index, data.length - 1))) — doesn't apply here; the negative value originates from initialNumToRender, not from initialScrollIndex/scroll-to-index. It wouldn't prevent the crash on first render.
• Skip rendering the FlatListWithScrollKey while windowHeight is below a threshold — would unmount/remount the list on every transient resize, lose scroll position and trigger extra pagination requests. Worse UX than a single Math.max.
• Patch React Native's VirtualizedList/initialNumToRenderOrDefault to clamp negatives — possible via patch-package, but the bug is on our side: passing a negative initialNumToRender has never been a valid contract. Fixing at the call site is smaller, easier to maintain, and avoids carrying an RN patch.

[wildan-m]

Proposal

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

On iOS (HybridApp), opening an expense report can crash with Invariant Violation: Invalid cells around viewport "[0, -4]" was passed to VirtualizedList._createRenderMask. Sentry shows 40,334 occurrences across 18,801 users since 2026-02-25, still ongoing on new.expensify@9.3.61-4. The component stack lands inside the FlatList rendered by MoneyRequestReportActionsList (the non-inverted money-report actions list, which uses FlatListWithScrollKey + useFlatListScrollKey for highlighted-action scrolling and progressive previous-item rendering).

What is the root cause of that problem?

The crash originates from the upstream React Native invariant check in VirtualizedList._createRenderMask:

https://github.com/Expensify/App/blob/740f820a39d2c0615afa313a79590d1c734e62ba/node_modules/%40react-native/virtualized-lists/Lists/VirtualizedList.js#L519-L524

The invariant requires three conditions: first >= 0, last >= first - 1, and last < itemCount. [0, -4] fails the middle one because -4 < 0 - 1 = -1. So cellsAroundViewport.last reached -4, which is two steps below the only legitimate negative value (-1, used to represent "no cells in range" when itemCount === 0).

That value is produced inside getDerivedStateFromProps in the maintainVisibleContentPosition branch:

https://github.com/Expensify/App/blob/740f820a39d2c0615afa313a79590d1c734e62ba/node_modules/%40react-native/virtualized-lists/Lists/VirtualizedList.js#L749-L761

When maintainVisibleContentPosition is active and the data changes such that the previously-tracked firstVisibleItemKey is found at index firstVisibleItemIndex, the adjustment is firstVisibleItemIndex - minIndexForVisible, and that adjustment is applied to both first and last of prevState.cellsAroundViewport. The result then flows through _constrainToItemCount:

https://github.com/Expensify/App/blob/740f820a39d2c0615afa313a79590d1c734e62ba/node_modules/%40react-native/virtualized-lists/Lists/VirtualizedList.js#L841-L860

_constrainToItemCount clamps first with clamp(0, cells.first, maxFirst) (so it can never go below 0), but last is only clamped to an upper bound: Math.min(lastPossibleCellIndex, cells.last). There is no lower bound. So if the adjusted cells.last is -4, the function returns last: -4 unchanged whenever lastPossibleCellIndex >= -4 (which is always — lastPossibleCellIndex is itemCount - 1 >= -1). The bad value then propagates back through getDerivedStateFromProps into the new state, and on the next render _createRenderMask blows up.

The trigger for cells.last going below -1 is a sequence where:

1. The previous state had cellsAroundViewport.last === -1 because itemCount had momentarily dropped to 0 (empty intermediate state — common in MoneyRequestReportActionsList because visibleReportActions is recomputed from several reactive Onyx inputs and can briefly evaluate to [] while reactions settle):

   App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

   Lines 153 to 178 in 740f820

   	const visibleReportActions = useMemo(() => {
   	const filteredActions = reportActions.filter((reportAction) => {
   	const isActionVisibleOnMoneyReport = isActionVisibleOnMoneyRequestReport(reportAction, shouldShowHarvestCreatedAction);
   	if (!isActionVisibleOnMoneyReport) {
   	return false;
   	}
   	const passesOfflineCheck = isOffline || isDeletedParentAction(reportAction) || reportAction.pendingAction !== CONST.RED_BRICK_ROAD_PENDING_ACTION.DELETE || reportAction.errors;
   	if (!passesOfflineCheck) {
   	return false;
   	}
   	const actionReportID = reportAction.reportID ?? reportID;
   	if (!isReportActionVisible(reportAction, actionReportID, canPerformWriteAction, visibleReportActionsData)) {
   	return false;
   	}
   	if (!isIOUActionMatchingTransactionList(reportAction, reportTransactionIDs)) {
   	return false;
   	}
   	return true;
   	});
   	return filteredActions.toReversed();
   	}, [reportActions, isOffline, canPerformWriteAction, reportTransactionIDs, shouldShowHarvestCreatedAction, visibleReportActionsData, reportID]);

2. Data then becomes non-empty again, but the previously-recorded firstVisibleItemKey is now at a small index (often 0), giving maintainVisibleContentPositionAdjustment = 0 - 1 = -1 (because useFlatListScrollKey sets minIndexForVisible: 1 whenever data.length >= 2):

   App/src/components/FlatList/hooks/useFlatListScrollKey.ts

   Lines 118 to 133 in 740f820

   	const maintainVisibleContentPosition = useMemo(() => {
   	if ((!initialScrollKey && (!isInitialData || !isQueueRendering)) || !shouldPreserveVisibleContentPosition) {
   	return undefined;
   	}
   	const config: ScrollViewProps['maintainVisibleContentPosition'] = {
   	// This needs to be 1 to avoid using loading views as anchors.
   	minIndexForVisible: data.length ? Math.min(1, data.length - 1) : 0,
   	};
   	if (shouldEnableAutoScrollToTopThreshold && !isLoadingData && !wasLoadingData) {
   	config.autoscrollToTopThreshold = AUTOSCROLL_TO_TOP_THRESHOLD;
   	}
   	return config;
   	}, [initialScrollKey, isInitialData, isQueueRendering, shouldPreserveVisibleContentPosition, data.length, shouldEnableAutoScrollToTopThreshold, isLoadingData, wasLoadingData]);

3. Apply adjustment: prev.last(-1) + adjustment(-1) = -2. _constrainToItemCount does not clamp below, so last: -2 survives. Once last is < -1, repeated cycles can drive it further down — -2, then -3, then -4 — until the next invariant check fires. The [0, -4] in the Sentry signature is the final value after the state has drifted across several updates.

The same negative-last is also accepted by the early-return path at the top of _adjustCellsAroundViewport:

https://github.com/Expensify/App/blob/740f820a39d2c0615afa313a79590d1c734e62ba/node_modules/%40react-native/virtualized-lists/Lists/VirtualizedList.js#L630-L637

which returns cellsAroundViewport unchanged whenever cellsAroundViewport.last < getItemCount(data), so the bad state survives _adjustCellsAroundViewport and ends up passed straight into _createRenderMask. iOS in HybridApp shows this most because the timing/RAF cadence on new.expensify@9.3.61-4 exposes the empty intermediate state more often than other platforms — but the underlying defect is platform-independent and lives in the JS layer.

The App already maintains a local patch on @react-native/virtualized-lists/Lists/VirtualizedList.js (patches/@react-native/virtualized-lists/@react-native+virtualized-lists+0.83.1+001+osr-improvement.patch), so this fix can be added in the same patch.

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

Extend the existing virtualized-lists patch so that _constrainToItemCount returns a last that always satisfies _createRenderMask's invariant. Concretely, after computing the upper-bounded last, also enforce last >= first - 1 (which collapses to "no cells in range" when the data has shrunk, instead of leaking a negative offset back into state). This is a one-line clamp inside the existing _constrainToItemCount return: clamp last to Math.max(first - 1, Math.min(lastPossibleCellIndex, cells.last)) using the already-computed first from clamp(0, cells.first, maxFirst). With this change:

• When data is empty (lastPossibleCellIndex === -1), the function returns {first: 0, last: -1} (unchanged behavior — max(-1, min(-1, X)) = -1 for any X).
• When data is non-empty but the inbound cells.last is artifically negative (e.g. -4), the function returns {first: 0, last: -1} instead of {first: 0, last: -4}, satisfying the invariant. On the very next _adjustCellsAroundViewport, the list will recompute a real viewport from the current scroll metrics.
• All currently-valid inputs are unaffected, because for any non-negative input cells.last >= 0 >= first - 1.

In parallel, harden the trigger in useFlatListScrollKey so the chance of the upstream library ever being handed an inconsistent prevState is reduced: when data is non-empty but data.length < 2, return undefined for maintainVisibleContentPosition instead of {minIndexForVisible: 0} (the fallback at line 125 of useFlatListScrollKey.ts). The current Math.min(1, data.length - 1) fallback to 0 is what causes firstVisibleItemKey to move from "key at index 1" to "key at index 0" when transitioning across small data sizes, which is one of the ways cells.last can be dragged below -1. Only enabling MVCP when there are at least two stable anchor items removes that specific drift without changing the highlighted-scroll behavior (which already only needs MVCP when displayedData is being progressively expanded, and that only happens when data.length is well above 2).

The fix needs to be made in two places:

• patches/@react-native/virtualized-lists/@react-native+virtualized-lists+0.83.1+001+osr-improvement.patch — extend with the last lower-bound clamp inside _constrainToItemCount.
• src/components/FlatList/hooks/useFlatListScrollKey.ts — return undefined from the maintainVisibleContentPosition memo whenever data.length < 2, instead of falling back to minIndexForVisible: 0.

No change is needed in MoneyRequestReportActionsList itself — it correctly passes the filtered visibleReportActions and the bug is purely in the FlatList layer that consumes it.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/90957-virtualizedlist-negative-last-crash?expand=1

What alternative solutions did you explore? (Optional)

• Fix only on the App side, by stabilizing visibleReportActions so it never briefly evaluates to [] between Onyx updates. This would require restructuring the useMemo to defer recomputation until all input keys are settled (e.g. via a deferred derived selector). It avoids the upstream patch but is more invasive, harder to verify, and leaves the same RN defect latent for every other FlatList in the App that uses maintainVisibleContentPosition with shrinking data.
• Catch the invariant and re-mount the FlatList with a key change. This recovers from the crash but discards scroll position and re-runs the expensive initial-render path on every empty/non-empty transition, which is a regression in UX for the money-report view.
• Disable maintainVisibleContentPosition entirely in useFlatListScrollKey. This kills the crash but breaks the progressive previous-item rendering used by highlighted-action deep links (?reportActionID=...) — the highlighted item would shift on every queued render. Not acceptable.