Non-Error exception captured with keys: Status

[ejain]

Platform:

• iOS
• Android

SDK:

• @sentry/react-native (>= 1.0.0)
• react-native-sentry (<= 0.43.2)

SDK version: 5.3.0

react-native version: 0.70.9

Are you using Expo?

• Yes
• No

Are you using sentry.io or on-premise?

• sentry.io (SaaS)
• on-premise

If you are using sentry.io, please post a link to your issue so we can take a look:

https://bloomtext.sentry.io/issues/3733362133/events/26b27f23f1d54e249ee5abcf51eb5e40/

Configuration:

(@sentry/react-native)

    Sentry.init({
      dsn: SENTRY_DSN
   })

---

I have following issue:

Sentry complains about a non-error being passed to captureException. This non-error appears to originate from within React Native (failed network requests?), so I'd expect Sentry to know how to capture it.

[krystofwoldrich]

Hi,
thank you for all the details, the screenshot, and the link.

We add the message Non-Error exception captured with keys: Status to inform you that the captured exception was a plain object without a stack trace. To give you as much information as possible we create a synthetic error to capture the current stack. The whole captured object can be found at the bottom of the issue page under Additional Data.

In this case, sadly there is not much info.

To get more information about failed HTTP requests use:

Sentry.init({
  enableCaptureFailedRequests: true,
});

or for more options HTTPClient integration.

[ejain]

@krystofwoldrich Thanks, hadn't seen that option in https://docs.sentry.io/platforms/react-native/configuration/options/... But if HTTP client errors are now supposed to be disabled by default, why is this one being captured? Additional Data shows { Status: timeout } -- perhaps failed requests without numeric status codes are not being recognized as failed requests?

[krystofwoldrich]

@ejain You are right HTTP client errors are disabled by default.

But this issue is created by Sentry.captureException compared to HTTP client errors created by patching the fetch and XHR functions as they don't throw on failed requests.

Seems like something in the code throws throw { Status: 'timeout' },

[ejain]

@krystofwoldrich The trace only includes framework code (ending with "Called from: node_modules/react-native/Libraries/Core/Timers/JSTimers.js in setTimeout").

[krystofwoldrich]

@ejain Yeah, the stack trace is not much of a help in this case.