Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

iOS: emitOnBrownfieldMessage: can crash with std::bad_function_call when native posts before JS requires the TurboModule (cold-start race)

未关闭
#420 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
48/100
Issue 类型
缺陷
描述清晰度
基本清楚
活跃度
冷清
技术栈
cpp, ios, objective-c, react-native
领域
api, mobile-dev

调研方向

从 ReactNativeBrownfieldModule.mm 中的 -handleNativeToJSMessage: 和 +emitMessageFromNative: 开始,然后跟踪 emitOnBrownfieldMessage: 到生成的 SpecBase callback 初始化过程。在 JS require TurboModule 之前重现或插桩一个 native post,并验证当 callback 不可用时,这条冷启动路径不再崩溃。

由索引模型根据 Issue 内容生成。

描述

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 _eventEmitterCallback invocation in a readiness check (or try/catch) inside the generated emitOnBrownfieldMessage:, or
  • Expose a callback/promise so host apps can gate native→JS postMessage calls on "TurboModule ready" rather than just "bundle loaded" (the closest signal startReactNative(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 against main/4.0.0 source)
  • iOS 26.x, React Native new architecture (TurboModules/Fabric)
主要语言
TypeScript
星标
552
派生
53
平均合并
5 天 9 小时
30 天内合并 PR
17

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

callstack/react-native-brownfield 的其他 Issue

查看 callstack/react-native-brownfield 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。