dd-sdk-reactnative
dd-sdk-reactnative copied to clipboard
React native crash when passing special context
Thanks for taking the time for reporting an issue!
If you are having trouble sending data from the SDK but don't see any error, please reach out first through our support team.
Describe what happened
DdRum.stopView(currentRoute.key, { action: [() => {} ]}, Date.now()) will error/crash with Malformed calls from JS: field sizes are different. Same for startView.
It seem specific to having a key containing an array that includes a function.
Steps to reproduce the issue: See snippet above
Describe what you expected: No crash Additional context
-
Version of the SDK
-
package.json"@datadog/mobile-react-native": "1.2.0-beta1", -
PodfileandPodfile.lock -
DatadogSDK (1.12.1)
-
DatadogSDKCrashReporting (1.12.1):
- DatadogSDK (= 1.12.1)
- PLCrashReporter (~> 1.11.0)
-
DatadogSDKReactNative (1.2.0-beta1):
- DatadogSDK (~> 1.12.0)
- DatadogSDKCrashReporting (~> 1.12.0)
- React-Core
-
android/build.gradleandandroid/app/build.gradleNot found
Hi @EvertEt, thanks for reaching out!
The context of events is sent to Datadog by native SDKs, through the React Native bridge. On the native side, we expect it to be something that can be serialized to JSON, and functions don't so the bridge returns that error.
You should put in the context only things that can be represented as JSON (like strings, numbers, booleans, arrays, objects, etc...).
I'm curious about your use case for this?
If you wish to pass a large object that contains functions to context, you can either format it to remove functions or simply call JSON.parse on it before to clean it :)
Hi, we don't have a specific use case for this. We're just using context to put all the parameters of the screen (from react-navigation). These parameters can also be functions, arrays...
I would suggest adding this information to the types, or doing a JSON parse+stringify in this library itself so it doesn't crash.
That's a good point indeed, I've added a task to add more safety to native SDKs if the expected native type is not met, it should go in our next release :)
I'm using @datadog/mobile-react-native:1.8.2 and still experiencing this issue.