Repository navigation
[0.88] Revert EventEmitter ArrayBuffer payload rejection (breaking for C++ TurboModules) #1418
Description
Target Branch
0.88
Link to commit or PR to be picked
Revert of react/react-native#58063 (ab2ea649e65) on 0.88-stable.
Description
0.88 is a non-breaking release. #58063 is a confirmed breaking change for C++ TurboModules and must not ship in it.
What it does
It adds a codegen parse-time guard, throwIfEventEmitterPayloadTypeIsUnsupported, that rejects ArrayBuffer as a TurboModule EventEmitter payload on all platforms:
export interface Spec extends TurboModule {
+onBuffer: EventEmitter<ArrayBuffer>;
}Why this is breaking, demonstrated
The same spec was run through both branches' codegen. It worked on 0.87 and is rejected on 0.88:
| 0.87.1 | 0.88-stable | |
|---|---|---|
| Parse | accepted | rejected |
GenerateModuleH (modulesCxx) |
succeeded | never runs |
GenerateModuleObjCpp |
threw, "Unsupported eventType" | never runs |
The C++ output on 0.87 is functional, not placeholder:
eventEmitterMap_["onBuffer"] = std::make_shared<AsyncEventEmitter<jsi::Value>>();
static_assert(bridging::supportsFromJs<OnBufferType, jsi::ArrayBuffer>, ...);
static_cast<AsyncEventEmitter<jsi::Value>&>(*eventEmitterMap_["onBuffer"]).emit(...)and the static_assert passes on 0.87, because struct Bridging<jsi::ArrayBuffer> with fromJs and toJs exists at react/bridging/ArrayBuffer.h:46 and is exported through the Bridging.h umbrella. modulesCxx is a consumer-facing codegen target.
So a C++ TurboModule with an ArrayBuffer event payload parsed, generated, compiled and had working bridging on 0.87, and its build fails on 0.88 with no code change by the consumer.
The iOS path already rejected it on 0.87, which is why this needed checking per generator target rather than once.
Scope
Surface: the codegen parser and generator files that implement the guard (error-utils.js, errors.js, parsers-commons.js, generators/modules/Utils.js, GenerateModuleH.js, GenerateModuleJavaSpec.js, GenerateModuleObjCpp/serializeEventEmitter.js).
0.88-only commits touching that surface, baseline v0.87.1:
ab2ea649e65#58063 — revert5bb96395949#57897,4bf55754905,5fb3ebce1ac— all predate it and add zero EventEmitter payload validation
Nothing lands after ab2ea649e65 on those files, so no later work conflicts. Both symbols it introduced (throwIfEventEmitterPayloadTypeIsUnsupported, UnsupportedModuleEventEmitterPayloadTypeParserError) are referenced only by files that commit itself created or modified, so the revert is self-contained.
Single commit. 23 files, all JavaScript under react-native-codegen, no native code.
Not reverted
d84c13d5111 (#57982, Java ArrayBuffer borrow contract) is annotated [Android][Breaking] but is not breaking for this release. All three Java ArrayBuffer TurboModule commits are 0.88-only, and 0.87's Android API snapshot contains no Java-facing ArrayBuffer type, only the C++ facebook::jsi::ArrayBuffer and facebook::react::AsyncArrayBuffer. No 0.87 consumer could have adopted it, so constraining it in 0.88 breaks nobody. The label is correct against main's history, not against the released line.
Verification
- Revert applies cleanly, no conflicts.
- After reverting, the same spec behaves identically to 0.87: parse accepted,
GenerateModuleHsucceeds,GenerateModuleObjCppthrows "Unsupported eventType". - Both introduced symbols are gone from the tree.
yarn jest packages/react-native-codegenpasses: 64 suites, 3122 tests, 1277 snapshots.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsDone / Picked
Activity
github-actions commentedon Sep 21, 2026
Thank you for opening a new React Native Pick Request.
These are the criteria we follow when accepting or rejecting a code change into a React Native release branch (source).
If your Pick Request does not satisfy the criteria below, please close it as it will not be considered.
✅ Which Pick Requests we accept
TurboModule.getEnforcingfunction is throwing an unexpected assertion error.react-native-macosis not behaving as expected or is regressingReactRootView.java) if it is causing a breaking change for the React Native ecosystem.❌ Which Pick Requests we don't accept
ℹ️ What makes for a good Pick Request
In order for your Pick Request to be considered, please do the following:
main, or one PR against the release branch.fabriziocucci commentedon Sep 21, 2026
Merged manually into
0.88-stableas070af03ab3b.Clean revert, no conflicts. Verified on the remote: both introduced symbols are gone, and
EventEmitter<ArrayBuffer>now behaves identically to 0.87 (parse accepted,GenerateModuleHsucceeds,GenerateModuleObjCppthrows "Unsupported eventType").yarn jest packages/react-native-codegenpasses with 64 suites and 3122 tests.#57982 was assessed alongside this and deliberately left in place, see the scope section above.