Path issue with Code Push

[Kerumen]

I use code-push for my application and when an error is generated the path is not well parsed. It looks like this:

Sentry with their client raven strip the path with a regex. I didn't find anything similar in the source code so I couldn't set up a PR.

[cooperka]

@Kerumen have you tried this? https://docs.bugsnag.com/platforms/react-native/showing-full-stacktraces/

[Kerumen]

@cooperka Yes and it works for Release and Debug. But when I upload my app on code push it doesn't work.
I guess the path is not the same and not stripped correctly.

[cooperka]

I just tried this out myself (we're also using CodePush) and it's pretty nasty. I was able to correctly symbolicate crashes by specifying the exact CodePush file URL when uploading sourcemaps (see snippet below) but that won't scale... every file URL could potentially be different for CodePush updates. Maybe if BugSnag accepted a glob for minifiedUrl? Otherwise a change might be needed in CodePush itself.

Here are the steps that will work for a single device, assuming you know the saved file location of the CodePush update binary on the device (e.g. when using a simulator) to use for minifiedUrl. It's the file shown in the symbolicated crash reports, e.g. the one in your screenshot.

code-push release-react YOUR_APP ios --sourcemapOutput ios/main.jsbundle.map

Quickly copy main.jsbundle from it's temporary location before CodePush deletes it (the path will be shown, e.g. Writing bundle output to: /var/folders/.../CodePush/main.jsbundle) and save it to ~/Downloads, then:

curl https://upload.bugsnag.com/ \
  -F apiKey=YOUR_API_KEY \
  -F appVersion=1.0.0 \
  -F minifiedUrl="file:///Users/yourself/Library/Developer/CoreSimulator/Devices/SIMULATOR_ID/data/Containers/Data/Application/APPLICATION_ID/Library/Application%20Support/CodePush/SOME_HASH/CodePush/main.jsbundle" \
  -F sourceMap=@ios/main.jsbundle.map \
  -F minifiedFile=@/Users/yourself/Downloads/main.jsbundle \
  -F overwrite=true

What a rough process.

It would be great to hear from some BugSnag owners on this one. @kattrali do you have any advice? What do you think about accepting globs for minifiedUrl?

[Kerumen]

Yes with the exact path that would work but I can't find it because when it's installed on CodePush it has the own device UUID in it so I can't guess it in advance.
And anyway, that's totally not viable. The solution would be to send globs for the URL as you said and as Sentry does.

By the way, when you run code-push release-react, it's not mandatory to quickly copy the main.jsbundle before it get deleted as you said because code-push runs react-native bundle under the hood so if you run this afterwards it will generate the same jsbundle that you can upload to Bugsnag.

[kattrali]

Thanks for the report, @Kerumen and for looking into it, @cooperka. We’re working on a better solution for this, but its good to know that file globs might be a workable solution. What do you think about potentially having an identifier for a given push, (like sourceMapsID) that we could correlate with an equivalent field in the crash metadata?

[cooperka]

@kattrali a sourceMapsId would work great, I would be very happy with that solution. That would also help differentiate the iOS and Android builds (currently I have to tweak my versionNumber to differentiate them when uploading sourcemaps).

[kattrali]

This has been fixed via #52, which is going out shortly 🎉

Thank you for the debugging help!

[cooperka]

Thanks for the update @kattrali! The PR isn't very detailed, and looks like it only changed the logic on iOS -- could you please explain how it will work now with CodePush? Do we just need to specify minifiedUrl=main.jsbundle and it will work with any path?

[kattrali]

Ah, no problem. There was an error in the logic for generating and stripping the base path on iOS, resulting in the source maps not matching what was sent in the stracktrace. I changed it to do proper URL quoting. Regarding the source map IDs suggestion, I mistakenly thought that was in another issue. This is something we’re working on. Would you mind sending a note via support@bugsnag.com so we can keep you posted, as this isn’t something I can fix on the library side?

The fix might potentially be specifying the CodePush identifier in the minifiedUrl, but I’ll need to confirm.

[cooperka]

Will do, thanks again :)

[cooperka]

@kattrali would you mind re-opening this issue until the real fix you're working on is added, just to prevent confusion? It's still an issue, though I understand it can't be resolved through this library alone.

[dwilt]

So I just came across this issue because we've just started using CodePush and realized that our sourcemaps broke (we didn't upload the CodePush bundle and maps to Bugsnag). Reading this though, it doesn't seem there is solution yet on how to deal with this, right?

[kattrali]

@dwilt Sorry about the confusion, I thought I'd updated this issue when we rolled out more comprehensive code push support. But yes, there is a solution! You can use the codeBundleId attribute when uploading source maps to prefer your code push bundle identifier to app version to prettify stacktraces. There's a corresponding blog post and updated source map upload documentation for React Native. Hope this helps!

[dwilt]

@kattrali Thanks for the response. I have been reading the blog post and documentation for this and I still can't get it it work. Here's my JS:

configuration.codeBundleId = `1.4.0-1492206275`;

and here is my upload script:

curl https://upload.bugsnag.com/ -F apiKey=HIDING-KEY-FOR-SECURITY -F codeBundleId=1.4.0-1492206275 -F minifiedUrl="main.jsbundle" -F sourceMap=@build/main.jsbundle.map -F minifiedFile=@build/main.jsbundle -F overwrite=true -F */index.ios.js=@index.ios.js

You can see that I have the codeBundleId matching both in the JS and in the curl script.

I have put a button in the JS that fires an error so I can test this. I see the error come into Bugsnag but it's not sourcemapped. When I upload a non-code-push version (using appVersion instead of codeBundleId), it works perfectly. Here's the error in Bugsnag:

file:///var/mobile/Containers/Data/Application/D5B5A316-552A-430A-8E37-691E80303E09/Library/Application%20Support/CodePush/6178264d64e123032eb2b925f5a3d870199cc5b62d104fe67d5fa9da24f77112/build/main.jsbundle:1108onPress

Any ideas?

[dwilt]

Also what's the point of this line?

-F */index.ios.js=@/workspace/app/index.ios.js

I changed @/workspace/app/index.ios.js to be @index.ios.js because that's the only index.ios.js file I know of and it's in the root of my project. It didn't seem to fix/break it though.

[bullmo]

@dwilt The codeBundleId configuration option was introduced in v2.1.0 of the react native notifier. It looks like you're using an older version of the notifier and therefore the field isn't being applied to the error reports (and consequently the associated source map for that codeBundleId isn't being picked up). When the field is applied it can normally be seen in the app tab on the event.

If you upgrade to the latest notifier you should be able to get source maps working with a code bundle id

[bullmo]

The line -F */index.ios.js=@/workspace/app/index.ios.js is an example of how to upload a source file alongside the source map. This is useful when the source map doesn't contain the source content. In those cases the code context won't be shown in Bugsnag unless you also upload the source files alongside the source map.

The field is optional and doesn't have to be provided. See the <sources> field description in the docs for more details.

[dwilt]

@bullmo Thanks for the response.

If you upgrade to the latest notifier you should be able to get source maps working with a code bundle id

Can you give me an example of the latest notifier? I'm a bit lost at what you mean.

Also, thanks for the response about the source map line.

[bullmo]

@dwilt By latest notifier I mean the latest version of bugsnag-react-native (which is 2.2.0). Please note that this works with react native v0.40.0 or later

[dwilt]

@bullmo Got it. I tried updating (to 2.2.0) and I'm still not seeing the errors. I can see the source maps are uploaded successfully and the codeBundleId as attached properly (these were working showing here before updating to 2.2.0 though):

Here's how the errors are coming in:

[bullmo]

@dwilt Looking at that stacktrace it seems that the release (dev=false) bundle file might have been uploaded for a debug (dev=true) stacktrace.

I can see that you currently have a thread ongoing in support around the source map issues. I'll continue this in there and get more info to help diagnose the issue

[iamtommcc]

@bullmo We've also had unending troubles with getting sourcemaps working in production with CodePush.

• Our sourcemaps are being correctly uploaded to Bugsnag with the right Source URL (just "main.jsbundle" for iOS, "index.android.bundle" for Android) & a code bundle ID set.
• Our errors are coming in with the "codeBundleId" showing up under the App tab.
• Despite error code bundle IDs exactly matching up with uploaded source maps, the sourcemaps are simply not being applied on either iOS or Android. We get the super long paths shown in the OP.

[bullmo]

@iamtommcc It looks like the filename reported when using CodePush is including the full path to the bundle file rather than just the name of the bundle file. This means that it's not matching against just "main.jsbundle".

We can look into whether we can strip these paths from the error report so that it's more consistent (and easier to read).

In the meantime if you use wildcards for the minifiedUrl field when uploading the source map (e.g. *main.jsbundle) it should get applied correctly.

[dwilt]

@iamtommcc if you get it working via @bullmo's suggestion, would you mind sharing how you're getting this all to work? We are still unable to have this working.

[duhseekoh]

I recently incorporated codepush into our app, and needed to upgrade bugsnag. I was running into the same issue, where the stacktrace contains the full file:///...main.jsbundle path, and in the bugsnag UI, even though the codeBundleId was set correctly and I verified I had a sourcemap uploaded corresponding to that bundle id, i wouldn't get correctly mapped errors.

@bullmo 's suggestion worked for me, adding *main.jsbundle for the minified url:

curl https://upload.bugsnag.com/ \
  -F apiKey=$BUGSNAG_API_KEY\
  -F codeBundleId=$PACKAGE_VERSION \
  -F minifiedUrl="*main.jsbundle" \
  -F sourceMap=@$BITRISE_SOURCE_DIR/ios/main.jsbundle.map \
  -F minifiedFile=@$BITRISE_SOURCE_DIR/ios/main.jsbundle \
  -F overwrite=true

This works ^

Ideally, bugsnag doesn't include the entire path of the jsbundle, not sure if that's possible.

[dwilt]

@duhseekoh thanks so much for pointing out the asterisk. This seems to have been what we were missing!

[iamtommcc]

Yeah, we got it working with the asterisk too - hooray! The source maps are often 10-20 lines misalinged, but that's probably another issue.

I think the docs should probably be updated to include the asterisk as currently they explicitly tell you to use just main.jsbundle for CodePush, which doesn't work.

[dwilt]

Yea, we're noticing that too. They are actually quite misaligned. So misaligned that we aren't even relying on them anymore actually :(

[kattrali]

@iamtommcc @dwilt would you mind sending an example of a misaligned stacktrace to support@bugsnag.com so we can take a look at the report and the source map and see if this is something we can fix?

[dwilt]

Here's one.

Link: https://app.bugsnag.com/great-jones-street/greatjonesstreet/errors/593062b06b4cc20018310b24?filters%5Bevent.since%5D%5B%5D=30d&filters%5Berror.status%5D%5B%5D=open

Screenshot:

The filename is completely wrong. This is an image file that it's saying there is an error undefined is not an object (evaluating 'e.id')

[kattrali]

Thanks!

[andriantosg]

Hi, does anyone know why I still got RCTFatalException: Unhandled JS Exception: while using CodePush? I've tried using *main.jsbundle on minified-url but unfortunately It didn't work. Am I missing something?

[kattrali]

@andriantosg Thanks for the report, I split your question into a separate issue.