Skip to content

Add enableMountingCoordinatorPullModelAndroid feature flag (#57581), defaulted on - #48

Merged
piaskowyk merged 2 commits into
rea4-discordfrom
piaskowyk/rea4-cherry-pick-mounting-coordinator-pull-model-flag
Sep 10, 2026
Merged

piaskowyk merged 2 commits into
rea4-discordfrom
piaskowyk/rea4-cherry-pick-mounting-coordinator-pull-model-flag

Conversation

@piaskowyk

Copy link
Copy Markdown

Summary

rea4-discord counterpart of #46 (same change, targeting rea4-discord instead of 0.86.0-discord). Both commits cherry-picked cleanly and the resulting diff is identical to that PR's.

Cherry-pick of facebook/react-native@ece0efe (facebook/react-native#57581), with the flag's default flipped from false to true.

enableMountingCoordinatorPullModelAndroid gates the Android pull-model mounting migration: the UI thread pulls the transaction itself via a PullTransactionMountItem enqueued in the MountItemDispatcher, rather than the commit thread pulling and building the mount batch in schedulerShouldRenderTransactions.

Two commits, so the upstream import and the Discord-specific default change stay reviewable apart:

  1. Add enableMountingCoordinatorPullModelAndroid feature flag (#57581) — the upstream cherry-pick, unchanged in behavior.
  2. Default enableMountingCoordinatorPullModelAndroid to true — the Discord default flip.

This is inert on this branch today

Worth being explicit, since the flag name suggests otherwise: flipping this default currently has no runtime effect. The upstream commit is flag-definition-only, 20 files of feature flag plumbing. There are no consumers of the flag in this branch, nor upstream at ece0efe. The implementation it gates lands in later upstream commits that are not cherry-picked here. PullTransactionMountItem appears in this tree only inside the flag's own description string.

The default is set to true now to record intent, so the path is on once the implementation is backported.

Relationship to usePullModelOnAndroid

This is a different, later migration than the pull model this fork already runs. usePullModelOnAndroid already defaults to true here and does have real consumers in FabricUIManagerBinding.cpp and FabricUIManager.java. Upstream has since removed that flag entirely, having graduated it. The new flag moves the pull down into the MountingCoordinator.

Dependencies to check before the implementation is backported

The flag description names prerequisites. Current state on this branch:

Flag Current default Required
enableAccumulatedUpdatesInRawPropsAndroid true always
enableExclusivePropsUpdateAndroid false when Props 2.0 is in use
enablePropsUpdateReconciliationAndroid false when Props 2.0 is in use

The latter two are still off, so they need revisiting when the migration actually turns on.

Notes on the cherry-pick

The generated feature flag files conflicted on the original 0.86.0-discord PR, because this fork's flag set has diverged from upstream (the fork carries extra flags, so flag ordering and the markFlagAsAccessed indices differ). Rather than hand-merging 19 generated files, the fork's versions were kept, the upstream change was applied to ReactNativeFeatureFlags.config.js (which merged cleanly), and the rest regenerated with yarn featureflags.

The resulting diff outside the config is exactly what you would expect: the new flag's accessors, the markFlagAsAccessed index shift for every alphabetically later flag, the accessedFeatureFlags_ array growing from 98 to 99, and updated SignedSource hashes. No existing flag was added, removed, or changed.

Neither app-side provider overrides the flag, so the default applies directly: ReactNativeNewArchitectureFeatureFlagsDefaults (Android) and ReactNativeFeatureFlagsOverridesOSSStable (iOS) both inherit it.

Test plan

  • A re-run of the generator reports no pending changes
  • Android builds

Made with Cursor

coado and others added 2 commits September 10, 2026 16:49
Adds the `enableMountingCoordinatorPullModelAndroid` experiment flag
(default off) that gates the Android pull-model mounting migration.
Config entry plus regenerated accessors only - no behavior change.

Cherry-pick of react/react-native@ece0efe.

The generated feature flag files conflicted because this fork's flag set
has diverged from upstream, so they were regenerated from the config with
`yarn featureflags` instead of being merged by hand.

Co-authored-by: Cursor <cursoragent@cursor.com>
Flip the flag's defaultValue to true and regenerate the feature-flag
boilerplate with `yarn featureflags --update`. The config's own metadata
already declared expectedReleaseValue: true.

Neither app-side provider overrides the flag, so the default applies
directly: ReactNativeNewArchitectureFeatureFlagsDefaults (Android) and
ReactNativeFeatureFlagsOverridesOSSStable (iOS) both inherit it.

Note: this is inert on this branch. The flag has no consumers here or
upstream at ece0efe -- that commit only defines it, and the migration it
gates (PullTransactionMountItem enqueued in MountItemDispatcher, so the UI
thread pulls the transaction instead of the commit thread building the
batch in schedulerShouldRenderTransactions) lands in later upstream
commits that are not cherry-picked here. Setting true now records intent
so the path is on once the implementation arrives.

This is a separate mechanism from usePullModelOnAndroid, which this fork
already defaults to true and which does have consumers in
FabricUIManagerBinding.cpp and FabricUIManager.java. Upstream has since
removed that flag, having graduated it.

Before the implementation is backported, check the dependencies named in
the flag description: enableAccumulatedUpdatesInRawPropsAndroid is already
true, but enableExclusivePropsUpdateAndroid and
enablePropsUpdateReconciliationAndroid are both still false, and the
latter two are required when Props 2.0 is in use.

Co-authored-by: Cursor <cursoragent@cursor.com>
@piaskowyk
piaskowyk merged commit 709dd62 into rea4-discord Sep 10, 2026
36 checks passed
@piaskowyk
piaskowyk deleted the piaskowyk/rea4-cherry-pick-mounting-coordinator-pull-model-flag branch September 10, 2026 14:55
piaskowyk added a commit that referenced this pull request Oct 13, 2026
…), defaulted on (#48)

* Add enableMountingCoordinatorPullModelAndroid feature flag (react#57581)

Adds the `enableMountingCoordinatorPullModelAndroid` experiment flag
(default off) that gates the Android pull-model mounting migration.
Config entry plus regenerated accessors only - no behavior change.

Cherry-pick of react/react-native@ece0efe.

The generated feature flag files conflicted because this fork's flag set
has diverged from upstream, so they were regenerated from the config with
`yarn featureflags` instead of being merged by hand.

Co-authored-by: Cursor <cursoragent@cursor.com>

* Default enableMountingCoordinatorPullModelAndroid to true

Flip the flag's defaultValue to true and regenerate the feature-flag
boilerplate with `yarn featureflags --update`. The config's own metadata
already declared expectedReleaseValue: true.

Neither app-side provider overrides the flag, so the default applies
directly: ReactNativeNewArchitectureFeatureFlagsDefaults (Android) and
ReactNativeFeatureFlagsOverridesOSSStable (iOS) both inherit it.

Note: this is inert on this branch. The flag has no consumers here or
upstream at ece0efe -- that commit only defines it, and the migration it
gates (PullTransactionMountItem enqueued in MountItemDispatcher, so the UI
thread pulls the transaction instead of the commit thread building the
batch in schedulerShouldRenderTransactions) lands in later upstream
commits that are not cherry-picked here. Setting true now records intent
so the path is on once the implementation arrives.

This is a separate mechanism from usePullModelOnAndroid, which this fork
already defaults to true and which does have consumers in
FabricUIManagerBinding.cpp and FabricUIManager.java. Upstream has since
removed that flag, having graduated it.

Before the implementation is backported, check the dependencies named in
the flag description: enableAccumulatedUpdatesInRawPropsAndroid is already
true, but enableExclusivePropsUpdateAndroid and
enablePropsUpdateReconciliationAndroid are both still false, and the
latter two are required when Props 2.0 is in use.

Co-authored-by: Cursor <cursoragent@cursor.com>

---------

Co-authored-by: Dawid Małecki <maleckidawid@meta.com>
Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants