sentry-react-native: Malformed calls from JS: field sizes are different

@dnl-jst Thank you for the message, as mentioned above you can try Release build then it will work.

Although the root of the issue is not in the SDK we are working on a fix.

@krystofwoldrich Based on the previous comment of @nkleidis

The error is logged in the console of “debug” builds (builds run on a simulator) and makes the app stop sending events to Sentry either when the debug option of Sentry init is true or false.

In the release builds we have not monitored if the error appears, but the Sentry SDK seems to be logging as expected, again either when the debug property of the Sentry init has the value of true or false.

This is the exact error we get:

And after running the code you provided in a previous comment we receive this:

 LOG  The problematic line code is in: RNSentry.captureEnvelope
 LOG  The problematic line code is in: Timing.createTimer

I am not sure if this can be helpful.

We get the same error as well during our react-native migration to 0.70.x. Versions: “@sentry/react-native”: “^5.8.0”, “react-native”: “0.70.13”,

As @dolakzdenek mentioned, the issue is happening only when debug is true. But I guess that when debug is turned off, all the issues are hidden. No?

Hi I am experiencing this also on

• @sentry/react-native 5.8.0
• react-native 0.71.12

First time it happened after react-native upgrade

Getting error:

 Sentry Logger [error]: Error while sending event: [Error: Exception in HostFunction: Malformed calls from JS: field sizes are different.

[[50,87],[6,0],[[354,100,1691572637387,false]],935]]

I followed this

Output:

LOG The problematic line code is in: RNSentry.captureEnvelope LOG The problematic line code is in: Timing.createTimer

Temp solution ✅

I experimented little bit with init() parameters. I found that it happened only when

debug: true

removing it or switching to false solved the problem I hope it helps someone to resolve it or identify the issue 🤞🏽

This started to happen to me as well after upgrading expo + react-native:

expo: 48.0.18 react-native: 0.71.13 @sentry/react-native: 4.15.2

The issue happens on iOS (haven’t checked on Android yet). And it affects only development builds. The problem doesn’t occur in production, neither when I use expo go.

Setting debug: false/true doesn’t seem to be making any difference to me.

I had to disable sentry on development by setting enableInExpoDevelopment: false to be able to run my app.

Is there any better workaround for this atm?

Its happening just in Debug builds. Release builds are ok.

@Aryk Thanks for the update, let us know when you do and if the problem is only in dev or release too.

@krystofwoldrich I have not had a chance to upgrade yet, but I will likely be upgrading straight to 5.8 when I upgrade my Expo and maybe the problem will disappear.

I believe I’ve found the issue. There seems to be a size limit to the parameter we can send over the bridge.

I’ve filed the envelopeBytes with non-sense data and got the same crash.

ERROR  Sentry Logger [error]: Error while sending event: [Error: Exception in HostFunction: Malformed calls from JS: field sizes are different.

[[11,25],[7,0],[[129,100,1677058975393,false]],418]]

for (let i = 0; i < 1e6; i++) {
  envelopeBytes.push(12);
}

await RNSentry.captureEnvelope(envelopeBytes, { store: hardCrashed });

@krystofwoldrich I finally got your debug code above to work and the result is the same as @TheTreek:

The problematic line code is in: Timing.createTimer

@TheTreek How did you track down the RNSentry.captureEnvelope()? Did you use this?

I tracked it down by putting console logs at all the points leading towards RNSentry.captureEnvelope() and saw that there were no logs after RNSentry.captureEnvelope() (on iOS)

Can you run the following code to decode the modules and method names?

I put that code in App.js right after Sentry.init() and got: The problematic line code is in: Timing.createTimer

@TheTreek How did you track down the RNSentry.captureEnvelope()? Did you use this?

Could you try to call this code to see what is moduleId 81 and methodId 0?

if (global.__fbBatchedBridge) {
  const origMessageQueue = global.__fbBatchedBridge;
  const modules = origMessageQueue._remoteModuleTable;
  const methods = origMessageQueue._remoteMethodTable;
  global.findModuleByModuleAndMethodIds = (moduleId, methodId) => {
    console.log(`The problematic line code is in: ${modules?.[moduleId]}.${methods?.[moduleId]?.[methodId]}`)
  }
}

global.findModuleByModuleAndMethodIds(81, 0);