react / react/react-native

[Android][Fabric] "Unable to remove a view from a view that is not a ViewGroup" still crashes with fixDifferentiatorParentTagForUnflattenCase enabled (0.86.2)

Open
#57,800 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Needs: Author Feedback Needs: Repro
Dominant language
C++
Stars
127k
Forks
25.3k
Avg merge
1d 23h
Merged PRs (30d)
4

Description

Description

We are still seeing the fatal Android Fabric crash

java.lang.IllegalStateException: Unable to remove a view from a view that is not a ViewGroup. ParentTag: 1902 - Tag: 1900 - Index: 0

in production with fixDifferentiatorParentTagForUnflattenCase enabled, on stock React Native 0.86.2 (new architecture, bridgeless, Hermes).

After #56542 ("Fix parentTagForUpdate in unflatten-unflatten branch") we backported the fix by force-enabling the flag at startup:

// Application.onCreate, after loadReactNative(this)
ReactNativeFeatureFlags.dangerouslyForceOverride(
    object : ReactNativeNewArchitectureFeatureFlagsDefaults() {
        override fun fixDifferentiatorParentTagForUnflattenCase(): Boolean = true
    }
)

We verified the override is effective (the dangerouslyForceOverride return value confirms the flag had not been read before the override, and the override happens in Application.onCreate before any surface is mounted). The crash volume dropped after enabling the flag, but the crash recurred in a build that provably contains it — so at least one more differ reparenting path can still emit a Remove mutation against a wrong parent tag (a tag whose ViewState holds a null or non-ViewGroup view, i.e. a non-container or a never-materialized/non-layoutable node).

Occurrence details from the crash session (Crashlytics):

  • Device: Samsung SM-S938W (Galaxy S25 Ultra), Android 16
  • The crashing tags (1900/1902) are mid-session views, not first-render views
  • Timeline: the session had two device orientation changes (portrait → landscape → portrait), then a large state-driven re-render (a BLE device connected and the dashboard swapped several conditional subtrees), and the crash fired ~7 s after that re-render began
  • The same differ family also produces the sibling hard throw "Cannot remove child at index X from parent ViewGroup" reported elsewhere (e.g. software-mansion/react-native-screens#2491)

Stack (top frames):

Fatal Exception: java.lang.IllegalStateException: Unable to remove a view from a view that is not a ViewGroup. ParentTag: 1902 - Tag: 1900 - Index: 0
    at com.facebook.react.fabric.mounting.SurfaceMountingManager.removeViewAt(SurfaceMountingManager.kt:444)
    at com.facebook.react.fabric.mounting.mountitems.IntBufferBatchMountItem.execute(IntBufferBatchMountItem.kt:125)
    at com.facebook.react.fabric.mounting.MountItemDispatcher.executeOrEnqueue(MountItemDispatcher.kt:379)
    at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems$lambda$7$lambda$6(MountItemDispatcher.kt:269)
    at com.facebook.react.internal.tracing.PerformanceTracer.trace(PerformanceTracer.kt:46)
    at com.facebook.react.fabric.mounting.MountItemDispatcher.dispatchMountItems(MountItemDispatcher.kt:250)
    at com.facebook.react.fabric.mounting.MountItemDispatcher.tryDispatchMountItems(MountItemDispatcher.kt:94)
    at com.facebook.react.fabric.FabricUIManager$DispatchUIFrameCallback.doFrameGuarded(FabricUIManager.java:1624)
    at com.facebook.react.uimanager.GuardedFrameCallback.doFrame(GuardedFrameCallback.kt:42)
    at com.facebook.react.modules.core.ReactChoreographer.frameCallback$lambda$1(ReactChoreographer.java:58)
    at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1899)
    ...

We could not reproduce locally (hundreds of scripted navigations/re-renders on the same screens stay clean); the reparenting race appears to need production timing. We're reporting because the flag from #56542 finished rollout and is default-true on main, so this evidences that the unflatten wrong-parent-tag family is not fully closed.

Workaround we ship meanwhile (in case it helps other affected apps): a build-time ASM transform that wraps SurfaceMountingManager.removeViewAt in try/catch (IllegalStateException) → log non-fatal → skip the remove. This matches the method's existing soft-fail handling of its other inconsistency cases, and addViewAt already self-heals a child that is still attached elsewhere. Not proposing that upstream — the differ emitting the wrong parent tag is the actual bug.

Happy to provide more Crashlytics context (thread dumps, breadcrumb timeline) on request.

Steps to reproduce

No deterministic repro. Observed pattern: device rotation (two orientation changes) followed by a large conditional re-render that flattens/unflattens nested views; crash fires during a subsequent mount batch.

React Native Version

0.86.2

Affected Platforms

Runtime - Android

Areas

Fabric - The New Renderer

Output of npx @react-native-community/cli info

React Native: 0.86.2 (new architecture, bridgeless)
React: 19.2.8
Expo: 57.0.4
Hermes: bundled
OS observed crashing: Android 16 (Samsung SM-S938W)
compileSdk/targetSdk: 36, minSdk: 24
AGP: 8.12.0, Gradle: 9.3.1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading SurfaceMountingManager.kt at removeViewAt and trace the Remove batch through IntBufferBatchMountItem.kt and MountItemDispatcher.kt. Compare the behavior with the fix from #56542 and investigate the orientation and conditional re-render sequence described; done means identifying and covering the remaining path that emits an invalid parent tag without relying on the production-only crash.

Written by the indexing model from the issue text.

Assessment

Tech stack
android, kotlin, react-native
Domain
mobile
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.