maps icon indicating copy to clipboard operation
maps copied to clipboard

[Bug]: Navigating away from Map causes unhandled promise rejection for "setHandledMapChangedEvents"

Open fractalscape13 opened this issue 1 year ago • 4 comments

Mapbox Implementation

Mapbox

Mapbox Version

default

React Native Version

0.72.6

Platform

iOS

@rnmapbox/maps version

10.1.19

Standalone component to reproduce

import React from 'react';
import {
  MapView,
  ShapeSource,
  LineLayer,
  Camera,
} from '@rnmapbox/maps';

const aLine = {
  type: 'LineString',
  coordinates: [
    [-74.00597, 40.71427],
    [-74.00697, 40.71527],
  ],
};

class BugReportExample extends React.Component {
  render() {
    return (
      <MapView style={{flex: 1}}>
        <Camera centerCoordinate={[-74.00597, 40.71427]} zoomLevel={14} />
        <ShapeSource id="idStreetLayer" shape={aLine}>
          <LineLayer id="idStreetLayer" />
        </ShapeSource>
      </MapView>
    );
  }
}

Observed behavior and steps to reproduce

I have a basic bottom tab navigation setup in my React Native app. Map is the first tab. Changing to any other tab from the map causes this error (I am getting 1000s of these events logged in Sentry):

WARN Possible Unhandled Promise Rejection (id: 2): Object { "code": "setHandledMapChangedEvents", "domain": "RCTErrorDomain", "message": "Unknown reactTag: 550", "nativeStackIOS": Array [ "0 app 0x0000000103283670 RCTJSErrorFromCodeMessageAndNSError + 112", "1 app 0x0000000103607798 ___ZZN8facebook5react15ObjCTurboModule13createPromiseERNS_3jsi7RuntimeENSt3__112basic_stringIcNS5_11char_traitsIcEENS5_9allocatorIcEEEEU13block_pointerFvU13block_pointerFvP11objc_objectEU13block_pointerFvP8NSStringSH_P7NSErrorEEENK3$_0clES4_RKNS2_5ValueEPSQ_m_block_invoke.116 + 440", "2 app 0x000000010415da59 __58-[RNMBXMapViewModule withMapView:block:reject:methodName:]_block_invoke + 425", "3 app 0x000000010329c5ec __30-[RCTViewRegistry addUIBlock:]_block_invoke + 108", "4 app 0x00000001032796a6 __44-[RCTUIManager flushUIBlocksWithCompletion:]_block_invoke + 374", "5 app 0x00000001032799b9 __44-[RCTUIManager flushUIBlocksWithCompletion:]_block_invoke.493 + 393", "6 app 0x0000000103281fda __RCTExecuteOnMainQueue_block_invoke + 26", "7 libdispatch.dylib 0x0000000129e29747 _dispatch_call_block_and_release + 12", "8 libdispatch.dylib 0x0000000129e2a9f7 _dispatch_client_callout + 8", "9 libdispatch.dylib 0x0000000129e3a856 _dispatch_main_queue_drain + 1362", "10 libdispatch.dylib 0x0000000129e3a2f6 _dispatch_main_queue_callback_4CF + 31", "11 CoreFoundation 0x0000000128617850 CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE + 9", "12 CoreFoundation 0x000000012861218b __CFRunLoopRun + 2463", "13 CoreFoundation 0x0000000128611409 CFRunLoopRunSpecific + 557", "14 GraphicsServices 0x000000012caa8187 GSEventRunModal + 137", "15 UIKitCore 0x00000001541b63a2 -[UIApplication _run] + 972", "16 UIKitCore 0x00000001541bae10 UIApplicationMain + 123", "17 app 0x00000001027153c0 main + 96", "18 dyld 0x0000000112d693ee start_sim + 10", "19 ??? 0x000000020ac373a6 0x0 + 8770515878", ], "userInfo": null, }

Expected behavior

No response

Notes / preliminary analysis

No response

Additional links and references

https://github.com/rnmapbox/maps/assets/45412175/10a50131-2fb2-4ce1-9539-44645b321d8c

fractalscape13 avatar May 17 '24 17:05 fractalscape13

We're experiencing this, as well (in 10.1.33 and 10.1.37 and 10.1.38). Our Sentry errors jumped from like 400 a month to maxing out the 10,000 errors logged in the free plan in just a couple days. My colleague says this is coming from:

this._runNativeMethod('setHandledMapChangedEvents', this._nativeRef, [
        events,
      ]);

RyanTG avatar Jan 03 '25 21:01 RyanTG

Same issue here on version 10.1.33.

boazpoolman avatar Feb 28 '25 16:02 boazpoolman

@mfazekas Any ideas for how this one could be resolved? All the errors are troublesome.

RyanTG avatar Apr 27 '25 05:04 RyanTG

This seems to not be occurring anymore for me in the following conditions:

  • Expo SDK 53
  • RN 0.79.2
  • rnmapbox 10.1.38
  • with this rnmapbox patch: https://github.com/rnmapbox/maps/issues/3753#issuecomment-2848435571

However, I did not incrementally update these things and check on this issue. So I'm not certain which one could have resolved it. My guess would be that sweet patch 😄

RyanTG avatar May 08 '25 17:05 RyanTG

this having this issu from months and don't know how to fix it . patch package with the following code don't fix it

+++ b/node_modules/@rnmapbox/maps/src/components/MapView.tsx
@@ -1171,6 +1171,15 @@ class MapView extends NativeBridgeComponent(
       }
     }
 
+    
+    if (mapView == null) {
+      mapView = (
+         <RNMBXMapView {...props} {...callbacks}>
+           {this.props.children}
+         </RNMBXMapView>
+       )
+    }

alainib avatar Jul 21 '25 14:07 alainib

I'm also experiencing Unknown reactTag issues being logged to Sentry in release mode.

@rnmapbox/maps: 10.1.40
react-native: 0.79.5

janisievins avatar Aug 15 '25 06:08 janisievins

I have since updated to react-native 0.81, Expo 54 and rnmapbox/maps 10.1.44 and I am not experiencing this anymore. Instead, I am getting occasional iOS only errors in Sentry. Various device types, started 5 days ago. I am still on v10 for the native mapbox sdk.

Could not find view with tag 632 in setHandledMapChangedEvents after 21 attempts over 208.7ms

fractalscape13 avatar Sep 24 '25 17:09 fractalscape13

@fractalscape13 thanks much, that's an useful feedback.

I have since updated to react-native 0.81, Expo 54 and rnmapbox/maps 10.1.44 and I am not experiencing this anymore. Instead, I am getting occasional iOS only errors in Sentry. Various device types, started 5 days ago. I am still on v10 for the native mapbox sdk.

Could not find view with tag 632 in setHandledMapChangedEvents after 21 attempts over 208.7ms

What we can try is increasing the timeout too see if reports decreases that way. On android such timeout were caused by permission dialog. Not sure if on iOS that would affect it, I don't think so.

mfazekas avatar Sep 24 '25 19:09 mfazekas

Hi @mfazekas I've opened a PR #4065 for this to increase the timeout to 500ms. We noticed 200ms work for simple map to be retrieved but for a more complex map 200ms is not enough and it will result the JS callbacks not being set.

yliu342 avatar Oct 30 '25 09:10 yliu342