Unhandled Promise Rejections

Due to an issue with React Native's dependencies, unhandled promise rejections might not be correctly caught by Sentry. If the promise rejection handler was not correctly attached, our SDK might issue a warning:

WARN: Unhandled promise rejections might not be caught by Sentry. Read about how to fix this on our troubleshooting docs.

Otherwise, we will let you know that the handler is attached:

[Sentry] Unhandled promise rejections will be caught by Sentry.

Auto Patching (Default Behavior)

By default we will patch the global Promise instance to ensure it matches exactly with the version that React Native uses.

Using With Other Polyfills

If you use a polyfilling library that patches the global Promise instance, you'll need to make sure you run the polyfill after Sentry.init is called.

import allSettled from "promise.allsettled";

  dsn: "",
// Any Promise polyfilling must occur AFTER Sentry.init
// This step globally patches Promise.

// Separate core-js example
import "core-js/stable/promise/all-settled";

Your linter might throw some errors here, but this step is necessary.

Disable Auto Patching

You can disable the global promise patching by passing patchGlobalPromise: false in either Sentry.init or the ReactNativeErrorHandlers integration. Note that if you disable our auto patching, to ensure that unhandled rejections are still caught, you will need to manually force a package resolution.

Manually Forcing a Package Resolution

You don't need to perform the steps below if you don't disable auto patching. You'll need to ensure that the version of promise that you use matches exactly with the version that React Native uses.

  1. Check the version of promise that your version of react-native uses. You can do this by going into node_modules/react-native/package.json and checking the version there, for example we find that it uses ^8.0.3:
  "dependencies": {
    // ...
    "promise": "^8.0.3"
  1. Add a package resolution with the same version as react-native's' to your package.json file, this will force this version to be used. You will then need to run a fresh yarn install or npm install to use the package resolution you just added.
  "resolutions": {
    "promise": "^8.0.3"
  1. If the fix is successful, our SDK will no longer display the above warning and will indicate that promise rejections will be caught.

Source Maps

When there is an issue with source maps on your event, there will usually be an error dialog at the top of the Issue Details page in

There was 1 problem processing this event: Source code was not found

Common fixes to this issue include:

  • Checking that both the release and dist and are set on the event by setting it in the call to init.
  • Checking that source maps are correctly uploaded with the exact same release and dist values as the event. They must match for source maps to upload correctly.
  • If you set a custom release and dist, confirming that you manually uploaded the sourcemaps since our automatic source map upload script will not detect the custom values.
  • Checking that you are not disabling the RewriteFrames default integration by overwriting it, filtering it out, or setting defaultIntegrations: false.

For more details, please read the guide on React Native source maps.

Source Maps With Hermes

Although the build script should already handle this for you most of the time, you may need to perform some extra steps when using the source maps with the Hermes engine. You can follow the guide here..

Different Bundles for Different Platforms

Your app could have different bundles for each platform that it supports, such as iOS and Android. To associate the correct bundle and sourcemap to each platform, you will need a unique release/dist combination for each platform. An easy way to do this is to include the platform name in the dist value.

iOS Build Script Failed

Try passing --force-foreground to the Sentry CLI command in the build script. This is possibly a bug with our CLI that we are investigating.

# ...
../node_modules/@sentry/cli/bin/sentry-cli react-native xcode \
  ../node_modules/react-native/scripts/ --force-foreground

Release Health

  • If your release health statistics are being attributed to the wrong release, confirm that you pass the release and dist to the init call.
  • If you are using Code Push, check that you are not using setRelease and setDist as they will break release health. You can read more on the CodePush guide.


If you use the sentry-expo SDK, make sure that you do not manually upgrade the version of the @sentry/react-native SDK and instead rely on the version that the sentry-expo SDK depends on. Upgrading could cause a version mismatch that could lead to errors being unreported and other undefined behavior. This is due to the sentry-expo SDK not being officially maintained by Sentry but instead by the Expo team.

Minified Names in Production

When bundling for production, React Native will minify class and function names to reduce the bundle size. This means that you won't get the full original component names in your Touch Event breadcrumbs or Profiler spans.

A way to work around this is to set the displayName on all the components you want to track with touch events or to pass the name prop to the Profiler components. However, you can also configure Metro bundler to not minify function names by setting these options in metro.config.js:

module.exports = {
  transformer: {
    minifierConfig: {
      keep_classnames: true, // Preserve class names
      keep_fnames: true, // Preserve function names
      mangle: {
        keep_classnames: true, // Preserve class names
        keep_fnames: true, // Preserve function names

Missing Context on Android NDK Events

If the context is missing on Android NDK events such as breadcrumbs, user, and so on, you need to enable the Scope Synchronization feature.

Help improve this content
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) to suggesting an update ("yeah, this would be better").