Sourcemaps - trouble getting them working consistently

1

Hi,

Wondering if we could get some advice, we’ve been trying to get Javascript source-maps loading consistently, but we’ve found that we’re intermittently (70%+ of the time) seeing messages like:

Remote file took too long to load: (15s, https://convert.yieldify.com/js/app.js?1485422904162)

Our main application bundle contains the correct trailing relative reference to the source-map, and when we don’t see the above messages stack-traces do seem to be resolved correctly.

(As a side-note we’re hosted on S3 in eu-west-1 with a Fastly CDN fronting the above domain, so I don’t actually believe the above is really taking 15s to resolve - however we’re trying to work-around this at the moment by using Sentry release file-sets to pre-cache these files with Sentry).

We had a look around the forums here and found this thread:

The implication seemed to be that we could upload our main application bundle as part of the release in Sentry, and that would short-circuit the need to download the application bundle in the first place. Typically (as of a day ago) our release in Sentry contains the files:

~/js/app.js
~/js/app.js.map
~/js/shims.js
~/js/shims.js.map

Is it the case that our cache-buster query parameter (e.g. ?1485422904162) could be defeating the resolution from our Sentry release file-set? Or are we barking up the wrong tree, and need to talk with Sentry support about why it’s taking 15s+ to load our main JS bundle?

We’re not using the X-SourceMap header on upload, as I can see it mentioned in various places, but not in the main Sentry docs or any example of how this should be used elsewhere? Not sure if this is needed or would help.

Thanks in advance,
Alan

1 Like
2

Yes. There’s an open PR (getsentry/sentry#4703) that addresses this that we’ve kind of stalled on.

I’ll look into reviving it.

3

The reason we did not end up doing it yet is because sentry-cli now writes out sourcemap references with the uploaded .min.js files which also resolves that issue.

Seems like you might want to explore sentry-cli in the interim.

4

Thanks for the confirmation! We changed our release script to include the cache-buster param, and for the moment Senty seems to be able to resolve our sourcemaps every-time*.

@benvinegar Is there any risk that https://github.com/getsentry/sentry/pull/4703 might stop this work-around from working?

  • 4 out of 4 attempts at least!