Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brownfield app crash after invalidating bridge and posting notification to NSNotificationCenter #42120

Open
gabrieldonadel opened this issue Jan 2, 2024 · 7 comments
Assignees
Labels
Needs: Attention Issues where the author has responded to feedback. Needs: Triage 🔍 p: Expo Partner: Expo Partner Type: New Architecture Issues and PRs related to new architecture (Fabric/Turbo Modules)

Comments

@gabrieldonadel
Copy link
Contributor

gabrieldonadel commented Jan 2, 2024

Description

I believe there is some sort of bridge invalidation bug in react native 0.73 when using Brownfield apps with the new arch on.

When an app invalidates a bridge, then creates a new bridge, and manually posts an RCTUserInterfaceStyleDidChangeNotification notification, the app crashes with an error stating that `"AccessibilityManager is nil"`` due to the module registry being nil inside RCTDeviceInfo. Seems something related to the reinitialization of the turbo modules.

This commit eb3d5a4b838ca7f632f02022e9be48402ca9d71f tried adding additional logging inside RCTDeviceInfo but that does not fix the issue and ended up causing the crash given the RCTAssert

Steps to reproduce

  1. Clone this repo
  2. Install the app with new arch enabled
  3. Run the app and select "Send UserInterfaceStyle event after invalidating"
  4. Press the "Invalidate and create new instance" button

React Native Version

0.73.1

Affected Platforms

Runtime - iOS

Areas

TurboModule - The New Native Module System

Output of npx react-native info

System:
  OS: macOS 14.0
  CPU: (12) arm64 Apple M2 Max
  Memory: 349.31 MB / 32.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.18.2
    path: ~/.volta/tools/image/node/18.18.2/bin/node
  Yarn:
    version: 1.22.19
    path: ~/.volta/tools/image/yarn/1.22.19/bin/yarn
  npm:
    version: 9.8.1
    path: ~/.volta/tools/image/node/18.18.2/bin/npm
  Watchman: Not Found
Managers:
  CocoaPods:
    version: 1.13.0
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.2
      - iOS 17.2
      - macOS 14.2
      - tvOS 17.2
      - visionOS 1.0
      - watchOS 10.2
  Android SDK:
    API Levels:
      - "22"
      - "26"
      - "30"
      - "31"
      - "33"
      - "34"
    Build Tools:
      - 26.0.3
      - 30.0.3
      - 31.0.0
      - 33.0.0
      - 33.0.1
      - 33.0.2
      - 34.0.0
    System Images:
      - android-22 | ARM 64 v8a
      - android-26 | Google APIs Intel x86_64 Atom
      - android-30 | ARM 64 v8a
      - android-33 | Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2022.3 AI-223.8836.35.2231.10811636
  Xcode:
    version: 15.2/15C5500c
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.8
    path: /usr/bin/javac
  Ruby:
    version: 2.7.8
    path: /Users/gabriel/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.73.1
    wanted: 0.73.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

Running "rn073BridgeInvalidation" with {"rootTag":1,"initialProps":{"concurrentRoot":true},"fabric":true}
W0102 13:13:20.019052 74891840 Scheduler.cpp:163] Scheduler::~Scheduler() was called (address: 0x600003306b20).
flipper: FlipperClient::addPlugin Inspector
flipper: Error: plugin Inspector already added.
flipper: FlipperClient::addPlugin Preferences
flipper: Error: plugin Preferences already added.
flipper: FlipperClient::addPlugin React
flipper: Error: plugin React already added.
flipper: FlipperClient::addPlugin Network
flipper: Error: plugin Network already added.
flipper: Already started
Invalidating <RCTCxxBridge: 0x104e08be0> (parent: <RCTBridge: 0x60000293ebc0>, executor: (null))
*** Assertion failure in -[RCTDeviceInfo _exportedDimensions](), /Users/gabriel/Workspace/expo/issues/rn073BridgeInvalidation/node_modules/react-native/React/CoreModules/RCTDeviceInfo.mm:127
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Failed to get exported dimensions: AccessibilityManager is nil'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000018048d8a8 __exceptionPreprocess + 172
	1   libobjc.A.dylib                     0x000000018008409c objc_exception_throw + 56
	2   Foundation                          0x0000000180d1bb90 -[NSMutableDictionary(NSMutableDictionary) classForCoder] + 0
	3   rn073BridgeInvalidation             0x0000000100c04b04 -[RCTDeviceInfo _exportedDimensions] + 828
	4   rn073BridgeInvalidation             0x0000000100c05fc4 -[RCTDeviceInfo _interfaceFrameDidChange] + 32
	5   rn073BridgeInvalidation             0x0000000100c05f68 __40-[RCTDeviceInfo interfaceFrameDidChange]_block_invoke + 40
	6   rn073BridgeInvalidation             0x0000000100bcc68c RCTExecuteOnMainQueue + 52
	7   rn073BridgeInvalidation             0x0000000100c05ef4 -[RCTDeviceInfo interfaceFrameDidChange] + 116
	8   CoreFoundation                      0x00000001803be03c __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 140
	9   CoreFoundation                      0x00000001803bdf60 ___CFXRegistrationPost_block_invoke + 84
	10  CoreFoundation                      0x00000001803bd450 _CFXRegistrationPost + 404
	11  CoreFoundation                      0x00000001803bce2c _CFXNotificationPost + 688
	12  Foundation                          0x0000000180d8f0c0 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
	13  rn073BridgeInvalidation             0x0000000100841378 -[AppDelegate sendUserInterfaceStyleNotification] + 340
	14  rn073BridgeInvalidation             0x000000010084118c __28-[AppDelegate buttonTapped:]_block_invoke + 164
	15  libdispatch.dylib                   0x00000001055c00f0 _dispatch_call_block_and_release + 24
	16  libdispatch.dylib                   0x00000001055c193c _dispatch_client_callout + 16
	17  libdispatch.dylib                   0x00000001055d15e4 _dispatch_main_queue_drain + 1228
	18  libdispatch.dylib                   0x00000001055d1108 _dispatch_main_queue_callback_4CF + 40
	19  CoreFoundation                      0x00000001803ee1b4 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
	20  CoreFoundation                      0x00000001803e88cc __CFRunLoopRun + 1936
	21  CoreFoundation                      0x00000001803e7d28 CFRunLoopRunSpecific + 572
	22  GraphicsServices                    0x000000018e7cdbc0 GSEventRunModal + 160
	23  UIKitCore                           0x00000001852bafdc -[UIApplication _run] + 868
	24  UIKitCore                           0x00000001852bec54 UIApplicationMain + 124
	25  rn073BridgeInvalidation             0x000000010084c300 main + 96
	26  dyld                                0x00000001045f5558 start_sim + 20
	27  ???                                 0x00000001046d2058 0x0 + 4369227864
	28  ???                                 0x7348800000000000 0x0 + 8307030250173235200
)
libc++abi: terminating due to uncaught exception of type NSException

Reproducer

https://github.com/gabrieldonadel/rn073BridgeInvalidation

Screenshots and Videos

292563657-75974536-da85-491c-967d-fc2b271a2808.mp4
@cipolleschi
Copy link
Contributor

Hi @gabrieldonadel, thanks for the report. I was able to run the reproducer and to verify that happen. Now we can work on a solution.
I wanted to verify how it should work on the Old Architecture, but couldn't revert the project to it.
Even by running

  • bundle exec pod install
  • RCT_NEW_ARCH_ENABLED=0 bundle exec pod install
    it was still building the New Arch.

What did you changed? How can I run the repro with the old arch?

@gabrieldonadel
Copy link
Contributor Author

Hi @gabrieldonadel, thanks for the report. I was able to run the reproducer and to verify that happen. Now we can work on a solution. I wanted to verify how it should work on the Old Architecture, but couldn't revert the project to it. Even by running

  • bundle exec pod install
  • RCT_NEW_ARCH_ENABLED=0 bundle exec pod install
    it was still building the New Arch.

What did you changed? How can I run the repro with the old arch?

Hi @cipolleschi, thanks for checking this, to avoid having to always run pod install with RCT_NEW_ARCH_ENABLED=0 I just added that to the env inside Podfile, you can change it here https://github.com/gabrieldonadel/rn073BridgeInvalidation/blob/main/ios/Podfile#L1

@github-actions github-actions bot added Needs: Attention Issues where the author has responded to feedback. and removed Needs: Author Feedback labels Jan 4, 2024
@cipolleschi
Copy link
Contributor

thanks, I missed that line! xD

@cipolleschi
Copy link
Contributor

Tested with the Old Arch, and it works without issues.
My guess is that we have 2 concurrent issues:

  1. a race condition or a deadlock that sometimes prevents the app from connecting to Metro.
  2. the event is sent before React Native is actually initialized, and the app is crashing.
    We need to address both.

Out of curiosity, did you tested this setup also with bridgeless? How does it behave?

@gabrieldonadel
Copy link
Contributor Author

Thanks for investigating this, I haven't tested with bridgeless yet but I can give it a shot later today

@gabrieldonadel
Copy link
Contributor Author

@cipolleschi I gave Bridgeless mode a test and things are much better but this race condition still happens if the bundle is invalidated + restarted a bunch of times in sequence (not an issue in real-world scenarios).

bridgeless.mp4

I've updated the repo to support bridgeless and you can toggle it on by replacing this value ->
https://github.com/gabrieldonadel/rn073BridgeInvalidation/blob/bdbe8933b97b56d959f28fda57f961af26dabf86/ios/BridgeDelegate.mm#L190

gabrieldonadel added a commit to expo/expo that referenced this issue Jan 8, 2024
# Why

Closes ENG-10953

When navigating to home from dev-menu in an app dev-client with new arch
enabled on iOS the app will crash due to `"AccessibilityManager is nil"
due to the registry is nil` inside `RCTDeviceInfo`.
This happens because when we invalidate the old bridge, create a new
one, and then manually post an
`RCTUserInterfaceStyleDidChangeNotification` notification, it gets
received by an old instance of RCTDeviceInfo and then fails to find the
module as the bridge is no longer valid.

Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher` fixes this racing condition issue and it doesn't
seem to create any problems related to UserInterfaceStyle

Created this issue on react-native core
facebook/react-native#42120

# How

- Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher`
- Add minimum support to dark mode on fabric-tester

# Test Plan



https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5



# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).
gabrieldonadel added a commit to expo/expo that referenced this issue Jan 8, 2024
# Why

Closes ENG-10953

When navigating to home from dev-menu in an app dev-client with new arch
enabled on iOS the app will crash due to `"AccessibilityManager is nil"
due to the registry is nil` inside `RCTDeviceInfo`.
This happens because when we invalidate the old bridge, create a new
one, and then manually post an
`RCTUserInterfaceStyleDidChangeNotification` notification, it gets
received by an old instance of RCTDeviceInfo and then fails to find the
module as the bridge is no longer valid.

Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher` fixes this racing condition issue and it doesn't
seem to create any problems related to UserInterfaceStyle

Created this issue on react-native core
facebook/react-native#42120

# How

- Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher`
- Add minimum support to dark mode on fabric-tester

# Test Plan



https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5



# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).
onizam95 pushed a commit to onizam95/expo-av-drm that referenced this issue Jan 15, 2024
# Why

Closes ENG-10953

When navigating to home from dev-menu in an app dev-client with new arch
enabled on iOS the app will crash due to `"AccessibilityManager is nil"
due to the registry is nil` inside `RCTDeviceInfo`.
This happens because when we invalidate the old bridge, create a new
one, and then manually post an
`RCTUserInterfaceStyleDidChangeNotification` notification, it gets
received by an old instance of RCTDeviceInfo and then fails to find the
module as the bridge is no longer valid.

Removing the `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher` fixes this racing condition issue and it doesn't
seem to create any problems related to UserInterfaceStyle

Created this issue on react-native core
facebook/react-native#42120

# How

- Remove `_ensureUserInterfaceStyleIsInSyncWithTraitEnv` call from
`navigateToLauncher`
- Add minimum support to dark mode on fabric-tester

# Test Plan



https://github.com/expo/expo/assets/11707729/54a6b68e-8db8-4296-8c9b-29fa314cafb5



# Checklist

<!--
Please check the appropriate items below if they apply to your diff.
This is required for changes to Expo modules.
-->

- [ ] Documentation is up to date to reflect these changes (eg:
https://docs.expo.dev and README.md).
- [ ] Conforms with the [Documentation Writing Style
Guide](https://github.com/expo/expo/blob/main/guides/Expo%20Documentation%20Writing%20Style%20Guide.md)
- [ ] This diff will work correctly for `npx expo prebuild` & EAS Build
(eg: updated a module plugin).
@cipolleschi
Copy link
Contributor

We have a lead on this. We have not forgotten it! :D
For reference, we need to try if this PR fixes: 8feb84a

cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 19, 2024
Summary:
Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 22, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 22, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 23, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 24, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 24, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 24, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
cipolleschi added a commit to cipolleschi/react-native that referenced this issue Jan 24, 2024
…#42396)

Summary:

Cmmunity reported [facebook#42120](facebook#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604
facebook-github-bot pushed a commit that referenced this issue Jan 24, 2024
Summary:
Pull Request resolved: #42396

Cmmunity reported [#42120](#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604

fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
blakef pushed a commit that referenced this issue Jan 25, 2024
Summary:
Pull Request resolved: #42396

Cmmunity reported [#42120](#42120) where React Native was crashing if RCTDeviceInfo native module was receiving a notification while the bridge is invalidating.

Upon investigation, I realized that:
1. The RCTDeviceInfo module is never invalidated
2. Observers are still observing even when the Bridge is in an invalidated state and it is not back up.

This change makes sure that we invalidate the `RCTDeviceInfo.mm` module and that we unregister the observers.

## Changelog:
[iOS][Fixed] - Make `RCTDeviceInfo` listen to invalidate events and unregister observers while invalidating the bridge

Reviewed By: RSNara

Differential Revision: D52912604

fbshipit-source-id: 1727bcdef5393b1bd5a272e2143bc65456c2a389
facebook-github-bot pushed a commit that referenced this issue Apr 4, 2024
…o module (#43737)

Summary:
Previous fix brings in #42396. Seems it's a mistake to re-add observer?
So let's remove it and also not `invalidate` method not be called twice.

## Changelog:

[IOS] [FIXED] - Remove invalidate observer instead of re-adding observer in DeviceInfo module

Pull Request resolved: #43737

Test Plan: Fix for #42120 also works.

Reviewed By: javache

Differential Revision: D55692219

Pulled By: cipolleschi

fbshipit-source-id: dba1ddc39a9f2611fc2b84fadf8c23827891379a
cortinico pushed a commit that referenced this issue Apr 8, 2024
…o module (#43737)

Summary:
Previous fix brings in #42396. Seems it's a mistake to re-add observer?
So let's remove it and also not `invalidate` method not be called twice.

## Changelog:

[IOS] [FIXED] - Remove invalidate observer instead of re-adding observer in DeviceInfo module

Pull Request resolved: #43737

Test Plan: Fix for #42120 also works.

Reviewed By: javache

Differential Revision: D55692219

Pulled By: cipolleschi

fbshipit-source-id: dba1ddc39a9f2611fc2b84fadf8c23827891379a
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs: Attention Issues where the author has responded to feedback. Needs: Triage 🔍 p: Expo Partner: Expo Partner Type: New Architecture Issues and PRs related to new architecture (Fabric/Turbo Modules)
Projects
None yet
Development

No branches or pull requests

5 participants