Sentry breaks application when sourcemaps aren't included with application bundle

[nathanchapman]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/browser

SDK Version

7.73.0+

Framework Version

React 17.0.2

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

Upgraded from 7.72.0 to 7.73.0 (and later, tested up to 7.75.1 as well)
Upload source maps to sentry
Delete source maps from bundle e.g.

rm build/static/{js,css}/*.map
sed -i'' -e '/\/\/# sourceMappingURL.*/d' build/static/js/*.js
sed -i'' -e '/\/\*# sourceMappingURL.*/d' build/static/css/*.css

Deploy application (in our case, to Firebase)

Expected Result

Application loads as expected, like it did with 7.72.0 and earlier

Actual Result

Application fails to load with Uncaught (in promise) ChunkLoadError: Loading chunk 825 failed.

[AbhiPrasad]

Hey @nathanchapman - could you provide your SDK setup? Could you go into details about your firebase setup? How are you uploading sourcemaps?

The only major change in 7.73.0 was regarding session replay, are you using that?

Providing a minimal reproduction would also allow us to debug this faster. Thanks!

[nathanchapman]

Hey @AbhiPrasad thank you for the quick response!

We're uploading source maps with the GitHub Action https://github.com/getsentry/action-release/
Then we delete them from the application bundle using the snippet in the issue description
Then we deploy to Firebase with https://github.com/w9jds/firebase-action/

Nothing has changed with anything else, those dependencies are pinned and I've repeatedly confirmed it's the upgrade to 7.73.0 and above causing the issue.

We are not using session replay to my knowledge (EDIT: confirmed we are not). That's the most puzzling part of this (it took a very long time to narrow this down lol)

[AbhiPrasad]

If you remove the source maps github action (but still delete sourcemaps), does the error still occur?

This might be because we are using an outdated version of sentry-cli in the GitHub Action: getsentry/action-release#168

[nathanchapman]

If you remove the source maps github action (but still delete sourcemaps), does the error still occur?

Yes, that's actually how we handle PRs. The app is deployed to a preview "hosting channel" in Firebase but no source map upload to Sentry occurs since it's not a "release"

We were only deleting source maps on the workflow that runs on main ("live" hosting channel for development) so this wasn't caught in the original PR until after merged and deployed (because the preview channel worked fine / tests passed). I've confirmed it's only the combination of deleting sourcemaps + upgrading to @sentry/browser v7.73.0 and above, by adding the deletion of source maps to our PR workflow on a branch with the upgrade being the only other change. When I remove the delete sourcemaps step, the app with sentry 7.73.0+ loads just fine

The addition/removal of the sourcemap upload with getsentry/action-release had no affect

[AbhiPrasad]

So the error happens when you 1) run delete sourcemaps step 2) use 7.73.0+ of the SDK

I guess the deletion of # sourceMappingURL.* is causing problems. What happens when you call rm build/static/{js,css}/*.map but not strip the URL from the js files?

There is no logic in the SDK that aims to look for this, so I assume it may be a bundling issue of some kind. What bundler are you using?

[nathanchapman]

I guess the deletion of # sourceMappingURL.* is causing problems. What happens when you call rm build/static/{js,css}/*.map but not strip the URL from the js files?

great call! Removing this did the trick. Is it fine to leave those lines even if there are no sourcemaps in the bundle?

What bundler are you using?

webpack@5.89.0

[nathanchapman]

Seeing this now when I view the bundled resources

But there are no errors in the console, so that's a good sign

[AbhiPrasad]

Is it fine to leave those lines even if there are no sourcemaps in the bundle

yeah it's fine to leave it, all that happens is that dev-tools will display a warning like what you showed above.

One theory of why this is happening is that when you mutate the file after webpack has outputted it, it messes up the subresource integrity. So webpack generates an integrity based on it's outputted js and attaches that to the script tag in the HTML, but now the integrity doesn't match anymore because you've mutated the js file.

If you still want to remove the sourceMappingURL, you might have to do it as part of the webpack build process. Maybe an approach like https://www.npmjs.com/package/@rbarilani/remove-source-map-url-webpack-plugin works?

[AbhiPrasad]

Are you using something like https://www.npmjs.com/package/webpack-subresource-integrity?

[nathanchapman]

yeah it's fine to leave it, all that happens is that dev-tools will display a warning like what you showed above.

Brilliant, thank you so much for the help!

Are you using something like https://www.npmjs.com/package/webpack-subresource-integrity?

Nope!

Confirming that this is definitely the issue:
sed -i'' -e '/\/\/# sourceMappingURL.*/d' consumer-out/static/js/*.js

It's deleting the source map URL line (e.g.//# sourceMappingURL=825.1399cabb.chunk.js.map) in addition to the line before it (the bundled / minified js)
It's only happening in the bundle that includes Sentry. Not exactly sure why, but i'm guessing it has something to do with that regex

[AbhiPrasad]

thanks for helping debug this @nathanchapman - appreciate the help 😄

[nathanchapman]

If you still want to remove the sourceMappingURL, you might have to do it as part of the webpack build process. Maybe an approach like https://www.npmjs.com/package/@rbarilani/remove-source-map-url-webpack-plugin works?

I think we specifically weren't doing this because we didn't want to have to build twice

[nathanchapman]

thanks for helping debug this @nathanchapman - appreciate the help 😄

Huge thanks to you. I really appreciate the support and quick responses!