iOS: emitOnBrownfieldMessage: can crash with std::bad_function_call when native posts before JS requires the TurboModule (cold-start race)
Les mainteneurs répondent en général sous 4 jours
Personne n'a encore pris cette issue.
Évaluation
- Difficulté
- 4/5
- Temps estimé
- 3-5 jours
- Accessibilité débutants
- 48/100
- Type d'issue
- Bug
- Clarté
- Plutôt claire
- Activité
- Calme
- Stack technique
- cpp, ios, objective-c, react-native
- Domaine
- api, mobile-dev
Piste de recherche
Commencez dans ReactNativeBrownfieldModule.mm avec -handleNativeToJSMessage: et +emitMessageFromNative:, puis suivez emitOnBrownfieldMessage: jusqu’à l’initialisation du callback de SpecBase généré. Reproduisez ou instrumentez un post natif avant que JS ne requière le TurboModule, et vérifiez que ce chemin de démarrage à froid ne plante plus lorsque le callback est indisponible.
Rédigé par le modèle d'indexation à partir du texte de l'issue.
Description
ReactNativeBrownfieldModule.mm's +emitMessageFromNative: only checks that the Obj-C singleton exists before calling emitOnBrownfieldMessage::
+ (void)emitMessageFromNative:(NSString *)message {
if (_sharedInstance) {
[_sharedInstance emitOnBrownfieldMessage:@{ @"text": message }];
} else {
NSLog(@"ReactNativeBrownfieldModule is not initialized, dropping message");
}
}
_sharedInstance is set in -init, which runs as soon as the bridge/TurboModuleManager instantiates the Obj-C module. But the codegen SpecBase's _eventEmitterCallback (the std::function that emitOnBrownfieldMessage: invokes) is only populated inside the C++ SpecJSI constructor, which only runs when getTurboModule: fires — i.e. when JS actually evaluates TurboModuleRegistry.getEnforcing('ReactNativeBrownfield').
If a host app calls ReactNativeBrownfield.shared.postMessage(...) (→ posts BrownfieldMessageToJSNotification → handleNativeToJSMessage: → emitMessageFromNative:) after the Obj-C module exists but before JS has required the module — e.g. right as a hosting view controller's viewDidAppear fires on a cold app launch, racing bundle evaluation — _eventEmitterCallback is still empty, and calling it throws std::bad_function_call, crashing the whole app (uncaught C++ exception).
Confirmed still present on main (4.0.0) as of 2026-07-06 — emitMessageFromNative:'s guard is unchanged from what's below (also reproduced against 3.3.0 in our own app):
- (void)handleNativeToJSMessage:(NSNotification *)notification {
NSString *message = notification.userInfo[@"message"];
if (message) {
[ReactNativeBrownfieldModule emitMessageFromNative:message];
}
}
Suggested fixes
- Wrap the
_eventEmitterCallbackinvocation in a readiness check (or try/catch) inside the generatedemitOnBrownfieldMessage:, or - Expose a callback/promise so host apps can gate native→JS
postMessagecalls on "TurboModule ready" rather than just "bundle loaded" (the closest signalstartReactNative(onBundleLoaded:)currently offers).
Repro
Timing-dependent — we haven't produced a deterministic repro case, but the code path is unambiguous from source, and we hit it in production (Crashlytics, std::__1::bad_function_call: std::exception, 100% of occurrences within the first second of a session). Happy to share a sanitized stack trace if useful.
Environment
@callstack/react-native-brownfield: 3.3.0 (also read againstmain/4.0.0 source)- iOS 26.x, React Native new architecture (TurboModules/Fabric)
- Langage dominant
- TypeScript
- Étoiles
- 552
- Forks
- 53
- Merge moyen
- 5 j 9 h
- PR mergées (30 j)
- 17
Préparer son environnement
- Aucun Dockerfile ni fichier Docker Compose
- Aucun modèle de pull request
- Lire le guide de contribution
Par où commencer
- Lisez l'issue en entier, puis le guide de contribution du projet.
- Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
- Forkez le dépôt et travaillez sur une branche.
- Ouvrez une pull request qui référence le numéro de l'issue.
Autres issues de callstack/react-native-brownfield
-
`package:ios --add-spm-package`: allow project-declared extra XCFrameworks as binary targetsOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 55/100
callstack/react-native-brownfield#468 ·
Les mainteneurs répondent en général sous 4 jours
-
Difficulté 5/5 Plus d'une semaine Accessibilité débutants 38/100
callstack/react-native-brownfield#406 ·
Les mainteneurs répondent en général sous 4 jours
-
Common network layerPeut-être à nouveau libre @dratwas l’a pris il y a 2536 jours, et aucune pull request n’est ouverte. Ouverte
callstack/react-native-brownfield#23 · 1 personne assignée ·
Les mainteneurs répondent en général sous 4 jours
-
Add support for bottom tabsPeut-être à nouveau libre @krizzu l’a pris il y a 2536 jours, et aucune pull request n’est ouverte. Ouverte
callstack/react-native-brownfield#22 · 1 personne assignée ·
Les mainteneurs répondent en général sous 4 jours
-
Tests for libraryOuverte
Difficulté 4/5 3-5 jours Accessibilité débutants 42/100
callstack/react-native-brownfield#11 · 2 commentaires ·
Les mainteneurs répondent en général sous 4 jours
Toutes les issues de callstack/react-native-brownfield
Issues similaires
-
[Bug]: [MCP/CLI] Bare loopback IP addresses (127.0.0.1:port) and hosts with ports fail to navigate due to erroneous scheme inferencePeut-être pris @alok-108 l’a pris aujourd’hui. Ouverte
Difficulté 2/5 1-3 heures Accessibilité débutants 78/100
microsoft/playwright#43263 ·
Les mainteneurs répondent en général sous 1 jour
-
bug priority:medium
Difficulté 2/5 1-3 heures Accessibilité débutants 65/100
Les mainteneurs répondent en général sous 1 jour
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulté 1/5 Moins d'une heure Accessibilité débutants 75/100
lingdojo/kana-dojo#32018 · 1 commentaire · 5 réactions ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
paperclipai/paperclip#15751 ·
Les mainteneurs répondent en général sous 1 jour
-
Difficulté 2/5 1-3 heures Accessibilité débutants 72/100
BuilderIO/agent-native#7275 ·
Les mainteneurs répondent en général sous 1 jour