[Due for payment 2026-07-03] [$250] [Sentry: APP-3E3] HybridApp Android Fabric getViewState RetryableMountingLayerException

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-3E3

Impact (snapshot at filing)

• Users (total since first seen): 330
• Events: 475
• Users (last 14d, 9.4.x releases): 117
• First seen: 2025-12-31
• Last seen: ongoing
• Platform: Android HybridApp
• App version(s): 9.4.5–9.4.9
• Affected route(s): /search (SearchReport view)
• Mechanism: UncaughtExceptionHandler

Stack trace (top frames, first-party only)

com.facebook.react.fabric.mounting.SurfaceMountingManager.getViewState
com.facebook.react.fabric.mounting.SurfaceMountingManager.addViewAt
com.facebook.react.fabric.mounting.mountitems.IntBufferBatchMountItem.execute
com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems

Suspected cause

Fabric mounting race — mount item references a stale view tag after the view state was removed.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Prior GH issues: [$250] [Crash] Android: SurfaceMountingManager.getViewState #50482 (closed, same signature family, no Sentry ID)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022067265956277613779
• Upwork Job ID: 2067265956277613779
• Last Price Increase: 2026-06-17

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

[$250] [Sentry: APP-3E3] HybridApp Android Fabric getViewState RetryableMountingLayerException

What is the root cause of that problem?

I traced this to the path that handles APP, HybridApp, getViewState:

• src/libs/actions/HybridApp/index.ts:36 (connectWithoutView): Onyx.connectWithoutView({
• src/libs/actions/HybridApp/index.ts:46 (connectWithoutView): Onyx.connectWithoutView({
• src/libs/actions/HybridApp/index.ts:54 (connectWithoutView): Onyx.connectWithoutView({
• The local evidence matches this recurring failure shape: native callback assumes current policy/report still exists. Here, src/libs/actions/HybridApp/index.ts:36 and src/libs/actions/HybridApp/index.ts:46 do not agree on the same APP, HybridApp, getViewState value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/libs/actions/HybridApp/index.ts:36 to derive APP, HybridApp, getViewState from the matched app state path that owns this flow before the value is consumed.
• Carry the same normalized value through src/libs/actions/HybridApp/index.ts:46; that follows the safer family move to add the guard at the ownership boundary, not only at render, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Sentry Crash, Null/Undefined, Native Hybrid surface and avoid changing do not hide crashes with blanket catch, native platform differences.

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

1. Add or update a regression in tests/unit/**/*.ts for the exact issue flow: [$250] [Sentry: APP-3E3] HybridApp Android Fabric getViewState RetryableMountingLayerException.
2. Cover the counter-case near src/libs/actions/HybridApp/index.ts:36 so valid existing APP, HybridApp, getViewState behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep APP, HybridApp, getViewState consistent at the first read/write boundary shown above.

[lorretheboy]

Proposal

What is the root cause of that problem?

The native Search list renders inside a FlashList that is given removeClippedSubviews:

App/src/components/Search/SearchList/BaseSearchList/index.native.tsx

Line 44 in 6513211

removeClippedSubviews

removeClippedSubviews is a legacy ScrollView optimization that makes Android imperatively detach and re-attach child views from their parent ViewGroup as they cross the clipping rect — work done outside of Fabric's knowledge. At the same time, FlashList v2 (2.3.0) is recycling cells, and the expandable report-group rows mount/unmount their GroupChildrenContent subtree on every expand/collapse:

App/src/components/Search/SearchList/ListItem/GroupChildrenContainer.tsx

Lines 50 to 88 in 6513211

	if (!isExpanded && !isRendered) {
	return <View />;
	}
	return (
	<Animated.View
	style={[
	styles.mh5,
	{backgroundColor: isSelected ? theme.activeComponentBG : theme.highlightBG},
	animatedHighlightStyle,
	isLastItem && [styles.tableBottomRadius, styles.overflowHidden],
	]}
	>
	<Animated.View style={animatedStyle}>
	{isContentVisible ? (
	<Animated.View
	style={[styles.stickToTop, styles.pb1]}
	onLayout={onLayout}
	>
	<GroupChildrenContent
	item={item}
	isExpanded={isContentVisible}
	groupBy={groupBy}
	searchType={searchType}
	columns={columns}
	canSelectMultiple={canSelectMultiple}
	onSelectRow={onSelectRow}
	onCheckboxPress={onCheckboxPress}
	onLongPressRow={onLongPressRow}
	nonPersonalAndWorkspaceCards={nonPersonalAndWorkspaceCards}
	onUndelete={onUndelete}
	newTransactionID={newTransactionID}
	bankAccountList={bankAccountList}
	cardFeeds={cardFeeds}
	conciergeReportID={conciergeReportID}
	/>
	</Animated.View>
	) : null}
	</Animated.View>

So the causal chain is: removeClippedSubviews strips a subview and disposes its ViewState behind Fabric's back → a queued IntBufferBatchMountItem (addViewAt) still references that view tag → SurfaceMountingManager.getViewState can't find the state → RetryableMountingLayerException, surfaced through UncaughtExceptionHandler. This is Android/Fabric-only, which is why the web variant — same prop, no Fabric — doesn't crash. On the new architecture FlashList already does its own windowing/recycling, so removeClippedSubviews is both redundant and the trigger (it's the only added knob the native variant doesn't strictly need).

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

Drop the removeClippedSubviews prop from the native Search FlashList here:

App/src/components/Search/SearchList/BaseSearchList/index.native.tsx

Line 44 in 6513211

removeClippedSubviews

FlashList v2 virtualizes off-screen rows itself, so removing the prop keeps the memory/scroll behavior while eliminating the imperative view detaching that races with Fabric's mount items. The web variant keeps the prop (harmless without Fabric), or it can be removed there too for consistency:

App/src/components/Search/SearchList/BaseSearchList/index.tsx

Line 187 in 6513211

removeClippedSubviews

After the change, regression-test scrolling and rapidly expanding/collapsing groups on the /search report view on an Android HybridApp build.

What alternative solutions did you explore? (Optional)

The repo already soft-logs (instead of crashing) the sibling updateProps case via a RN patch:

https://github.com/Expensify/App/blob/6513211aec3c051f53cffd8e3f42074dd383ce28/patches/react-native/react-native+0.83.1+027+log-soft-exception-if-viewState-not-found.patch

The same null-ViewState guard could be extended to the addViewAt path. That stops the crash but only masks the symptom — it leaves the imperative-clipping/Fabric race in place (views may still mount in the wrong place), so it's a fallback rather than the fix.

[MelvinBot]

Proposal

⚠️ Note for reviewer: the existing proposal above (pointing at src/libs/actions/HybridApp/index.ts) is not related to this crash. That file has nothing to do with Fabric view mounting — the crash is in React Native's native Android mounting layer, not in any Onyx connection.

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

Android HybridApp crashes with RetryableMountingLayerException: Unable to find viewState for tag X originating in React Native's Fabric mounting layer (SurfaceMountingManager.getViewState ← addViewAt), most often on the /search view.

What is the root cause of that problem?

This is a known React Native Fabric mounting race — not an App business-logic bug. When transactions are merged and reordered within a single mount cycle, a CREATE/INSERT mount item can end up referencing a parentTag whose ViewState was already deleted in the reordered batch. addViewAt then calls the throwing variant getViewState(parentTag), which raises RetryableMountingLayerException and crashes the app.

• The throw site: SurfaceMountingManager.getViewState raises RetryableMountingLayerException when mTagToViewState.get(tag) is null.
• The unguarded caller: addViewAt(...) calls getViewState(parentTag) (and getViewState(tag)) directly, with no null-safety — this exactly matches the reported stack (getViewState ← addViewAt ← IntBufferBatchMountItem.execute).

This is the same crash family as the prior fixes:

• Expensify/App#50482 / #50463 → patched on RN 0.75.2 via PR #53313 (a C++ transaction-reordering fix that no longer exists; App is now on RN 0.83.1).
• Expensify/App#82611 → patched via PR #84303, which added the current patch react-native+0.83.1+027+log-soft-exception-if-viewState-not-found.patch. That patch converts the updateProps path to use getNullableViewState + a soft exception — but it does not cover the addViewAt path, which is the one crashing here.

Code evidence (RN 0.83.1, node_modules)

ReactAndroid/.../fabric/mounting/SurfaceMountingManager.java:

// addViewAt — unguarded, crashes
public void addViewAt(final int parentTag, final int tag, final int index) {
  UiThreadUtil.assertOnUiThread();
  if (isStopped()) { return; }
  ViewState parentViewState = getViewState(parentTag);   // <-- throws RetryableMountingLayerException
  ...
  ViewState viewState = getViewState(tag);               // <-- also throwing variant

// getViewState — the throw site
private @NonNull ViewState getViewState(int tag) {
  ViewState viewState = mTagToViewState.get(tag);
  if (viewState == null) {
    throw new RetryableMountingLayerException(
        "Unable to find viewState for tag " + tag + ". Surface stopped: " + isStopped());
  }
  return viewState;
}

Upstream RN already uses the safe getNullableViewState + ReactSoftExceptionLogger.logSoftException pattern in many sibling methods in this same file (e.g. removeViewAt, deleteView, updateLayout, and the App-patched updateProps). addViewAt was simply never converted.

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

Extend the existing patch-package patch (in the App repo, so this is actionable here) to make addViewAt defensive, mirroring the already-accepted approach used for updateProps in patch #027:

• In addViewAt, replace getViewState(parentTag) / getViewState(tag) with getNullableViewState(...).
• If either is null, call ReactSoftExceptionLogger.logSoftException(...) with the existing SURFACE_MOUNTING_MANAGER_MISSING_VIEWSTATE category and return early instead of throwing — the dropped mount item is recoverable, and the next consistent transaction re-renders the view.
• Add the new patch under patches/react-native/ and document it in patches/react-native/details.md, referencing this issue and the upstream RN discussion.

This converts a hard crash into a soft-logged, recoverable no-op, exactly as the team already chose to do for the updateProps variant.

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

This is a native-layer (Java) patch, so JS unit tests can't exercise it directly. Verification should be:

1. Confirm the patch applies cleanly and the app builds for Android HybridApp.
2. Manual/QA smoke of the /search view with rapid navigation and offline→online transitions to confirm no crash.
3. Monitor Sentry APP-3E3 for a drop in events and a corresponding rise in the soft-exception log category after release.

What alternative solutions did you explore? (Optional)

• Re-port the upstream reordering fix (the RN 0.75.2 approach from PR [No QA] Fix CREATE mutations being dropped by merging transactions #53313) to RN 0.83.1 — addresses the true root cause but is a much larger, riskier C++ change and may already be partially upstreamed.
• Wait for / cherry-pick an upstream RN fix and drop the patch on the next RN bump — preferable long-term, but doesn't stop the bleeding now.

The soft-exception patch matches the team's existing precedent (#027) and is the lowest-risk stop-gap.

---

Related issues

• Expensify/App#82611 — same RetryableMountingLayerException family; fixed for the updateProps path via PR fix(react-native): log soft exception for missing viewState #84303.
• Expensify/App#50482 / Expensify/App#50463 — same family on RN 0.75.2; fixed via PR [No QA] Fix CREATE mutations being dropped by merging transactions #53313.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement this to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[yusufdeveloper2903]

Proposal

What is the root cause of that problem?

RetryableMountingLayerException thrown from SurfaceMountingManager.getViewState ← addViewAt is a New-Architecture (Fabric) mounting crash: a queued IntBufferBatchMountItem (addViewAt) references a view tag whose ViewState was already removed from mTagToViewState, so the throwing getViewState variant blows up. The trigger is one App-side prop: removeClippedSubviews enabled on the lists rendered on /search.

removeClippedSubviews is a legacy ScrollView optimization that makes Android imperatively detach / re-attach child views from their parent ViewGroup as they cross the clipping rect — mutations done outside Fabric's mounting transaction. When that imperative detach disposes a view's ViewState behind Fabric's back, the next batched addViewAt mount item still points at that tag → getViewState returns null → throw. It is Android/Fabric-only, which is exactly the platform in the Sentry report (the web variant has the same prop but no Fabric mounting layer, so it never crashes).

On /search this prop is set in two places, and the second one is the stronger suspect because it is a core React Native FlatList (where removeClippedSubviews is the textbook cause of this crash), not a FlashList:

1. The static results list shown during submit-and-navigate — a core FlatList with removeClippedSubviews:
   

   App/src/components/Search/SearchStaticList.tsx

   Lines 366 to 372 in 968eccd

   	<FlatList
   	data={sortedData}
   	renderItem={shouldUseNarrowLayout ? renderItem : (info) => renderWideItem(info, sortedData.length)}
   	keyExtractor={keyExtractor}
   	showsVerticalScrollIndicator={false}
   	contentContainerStyle={shouldUseNarrowLayout ? contentContainerStyle : styles.pb3}
   	removeClippedSubviews

2. The main results list — a FlashList v2 wrapped in Animated.createAnimatedComponent, with removeClippedSubviews:
   

   App/src/components/Search/SearchList/BaseSearchList/index.native.tsx

   Lines 32 to 51 in 968eccd

   	<AnimatedFlashListComponent
   	data={data}
   	renderItem={renderItemWithoutKeyboardFocus}
   	keyExtractor={keyExtractor}
   	onScroll={onScroll}
   	showsVerticalScrollIndicator={false}
   	ref={ref}
   	onEndReached={onEndReached}
   	onEndReachedThreshold={onEndReachedThreshold}
   	ListFooterComponent={ListFooterComponent}
   	onViewableItemsChanged={onViewableItemsChanged}
   	onLayout={onLayout}
   	removeClippedSubviews
   	drawDistance={250}
   	contentContainerStyle={contentContainerStyle}
   	maintainVisibleContentPosition={{disabled: true}}
   	stickyHeaderIndices={stickyHeaderIndices}
   	getItemType={getItemType}
   	/>
   	);

Note that FlashListProps extends Omit<ScrollViewProps, "maintainVisibleContentPosition">, so removeClippedSubviews (inherited from ScrollViewProps/ViewProps) is simply forwarded onto the underlying native ScrollView — FlashList v2 (2.3.0) does its own windowing/recycling, so the prop adds zero benefit and only layers a second, Fabric-invisible view-detaching mechanism on top of FlashList's recycling. Same redundant-but-harmful situation on the web variant:

App/src/components/Search/SearchList/BaseSearchList/index.tsx

Line 187 in 968eccd

removeClippedSubviews

So: removeClippedSubviews imperatively strips a /search row and disposes its ViewState → a queued addViewAt still references that tag → SurfaceMountingManager.getViewState finds no state → RetryableMountingLayerException via UncaughtExceptionHandler, on Android HybridApp only.

This is already an established crash class in this repo, and the codebase's own fix is to not use the prop — not to patch RN:

• The report view (MoneyRequestReportView → MoneyRequestReportActionsList, i.e. the report opened from /search) explicitly sets removeClippedSubviews={false} "to keep elements in virtual tree", added for the same crash family in [Due for payment 2025-08-13] [$250] Composer - Edit compose box is not auto-focused when editing a message in report page #66988:

  App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

  Line 755 in 968eccd

  removeClippedSubviews={false}

• The canonical FlashList lists (BaseSelectionList, BaseSelectionListWithSections) deliberately do not pass removeClippedSubviews:

  App/src/components/SelectionList/BaseSelectionList.tsx

  Lines 622 to 642 in 968eccd

  	<FlashList
  	role={getListboxRole(canSelectMultiple)}
  	data={data}
  	renderItem={renderItem}
  	ref={listRef}
  	keyExtractor={(item) => item.keyForList}
  	extraData={extraData}
  	ListFooterComponent={listFooterContent}
  	ListFooterComponentStyle={style?.listFooterContentStyle}
  	scrollEnabled={scrollEnabled}
  	indicatorStyle="white"
  	keyboardShouldPersistTaps="always"
  	showsVerticalScrollIndicator={showScrollIndicator}
  	onEndReached={onEndReached}
  	onEndReachedThreshold={onEndReachedThreshold}
  	testID="selection-list"
  	style={style?.listStyle}
  	contentContainerStyle={[styles.pb3, style?.contentContainerStyle]}
  	initialScrollIndex={shouldScrollToFocusedIndexOnMount ? initialFocusedIndex : undefined}
  	onScrollBeginDrag={onScrollBeginDrag}
  	maintainVisibleContentPosition={{disabled: disableMaintainingScrollPosition}}

  and

  App/src/components/SelectionList/SelectionListWithSections/BaseSelectionListWithSections.tsx

  Lines 435 to 460 in 968eccd

  	<FlashList
  	role={getListboxRole(canSelectMultiple)}
  	data={flattenedData}
  	renderItem={renderItem}
  	ref={listRef}
  	extraData={flattenedData.length}
  	getItemType={getItemType}
  	initialScrollIndex={initialScrollIndex ?? initialFocusedIndex}
  	keyExtractor={(item) => ('flatListKey' in item ? item.flatListKey : item.keyForList)}
  	onEndReached={onEndReached}
  	onEndReachedThreshold={onEndReachedThreshold}
  	onScrollBeginDrag={onScrollBeginDrag}
  	scrollEnabled={scrollEnabled}
  	onScroll={() => {
  	onScroll?.();
  	triggerScrollEvent();
  	}}
  	indicatorStyle="white"
  	showsVerticalScrollIndicator
  	keyboardShouldPersistTaps="always"
  	ListHeaderComponent={customListHeaderContent}
  	ListFooterComponent={listFooterContent}
  	ListFooterComponentStyle={style?.listFooterContentStyle}
  	style={style?.listStyle}
  	contentContainerStyle={style?.contentContainerStyle}
  	maintainVisibleContentPosition={{disabled: true}}

The Search lists are the outliers that re-introduced it.

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

Remove removeClippedSubviews from every list rendered on /search, matching the pattern the repo already settled on for the report view in #66988 (removeClippedSubviews={false} / omit it) and the canonical SelectionList FlashLists (which never set it):

1. SearchStaticList.tsx:372 — drop removeClippedSubviews from the core FlatList (this is the highest-risk instance: core FlatList + Fabric is the classic addViewAt/getViewState race).
2. BaseSearchList/index.native.tsx:44 — drop removeClippedSubviews from the FlashList; FlashList v2 already virtualizes off-screen rows, so scroll/memory behavior is unchanged.
3. BaseSearchList/index.tsx:187 — remove it on web too for consistency (harmless there, no Fabric).

This is the reuse-first fix: it converges the Search lists onto the exact convention already proven on MoneyRequestReportActionsList (#66988) and the SelectionList components, eliminating the imperative, Fabric-invisible view detaching that races with mount items. No new code, no RN patch, no behavior change. Minor changes/improvements can be discussed in the PR phase.

What alternative solutions did you explore? (Optional)

Patch RN's native SurfaceMountingManager.addViewAt to call getNullableViewState + ReactSoftExceptionLogger.logSoftException and early-return (mirroring the existing react-native+0.83.1+027+log-soft-exception-if-viewState-not-found.patch that already does this for the updateProps path). That only masks the symptom — the view still fails to mount in the right place, and it leaves the imperative-clipping/Fabric race in every other list that passes removeClippedSubviews. Removing the prop on /search fixes the actual trigger and aligns with the team's existing in-repo decision (#66988), so it's preferable; the patch is a reasonable defense-in-depth fallback but not the fix.

[github-actions]

⚠️ @yusufdeveloper2903 Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.