Sentry unable to load source maps from artifacts

mkormos · December 14, 2020, 11:34am

Sentry version: Sentry 20.11.1 14468076 (on-premise)
Operating system:

Operating System: Debian GNU/Linux 9 (stretch)
Kernel: Linux version 4.9.0-14-amd64
Architecture: x86-64

Sentry does not use source maps uploaded in artifacts. I’ve been trying to find out the reason for almost two days, but without success. My configuration seems to be all right.

Webpack plugin

Source maps are uploaded with Webpack plugin:

        new SentryWebpackPlugin({
            authToken,
            org,
            project,
            urlPrefix: "~/ng-maps/",
            release,
            url: "http://owtest.example.com:9000/",
            dist,
            include: "dist",
        }),

Source maps are not available online

After the source maps are uploaded to Sentry, we remove them so that they are not available online.

Release exists

When I check Sentry, there is a new release ow-5.2.1-20201120-343-gd58898f0c4f8

Artifacts are uploaded

When I check the artifacts in the release ow-5.2.1-20201120-343-gd58898f0c4f8, they are successfully uploaded:

For example, there is:

~/ng-maps/js/12.e13162ee90fd43b4654a.js
~/ng-maps/js/12.e13162ee90fd43b4654a.js.map

The `sourceMappingURL` is present

The following line is at the bottom of http://owtest.example.com/ng-maps/js/12.e13162ee90fd43b4654a.js:

//# sourceMappingURL=12.e13162ee90fd43b4654a.js.map

The artifact ~/ng-maps/js/12.e13162ee90fd43b4654a.js in Sentry has the same line at the bottom.

The source map file is valid

When I check the 12.e13162ee90fd43b4654a.js.map source map, I can see sourcesContent inside. The source map file is valid because Sentry loads it correctly when it is available online.

The source map file is small enough

$ du -bh 12.e13162ee90fd43b4654a.js*
48K	12.e13162ee90fd43b4654a.js
95K	12.e13162ee90fd43b4654a.js.map

The source map file is not gzipped

The source map file is not gzipped:

$ file 12.e13162ee90fd43b4654a.js*
12.e13162ee90fd43b4654a.js:     exported SGML document, ASCII text, with very long lines
12.e13162ee90fd43b4654a.js.map: JSON data

Issue and event JSON

When I simulate an exception in the application, I can see it as a new issue in Sentry:

Here is the event JSON. The abs_path contains “online” URL, but if I understand it correctly, it should pick the file from artifacts just by replacing the domain with ~.

The docker volumes are shared

The Sentry is installed in docker the common way (I followed the official guide and ran install.sh). I checked volumes of sentry_onpremise_cron_1, sentry_onpremise_web_1 and sentry_onpremise_worker_1. All point to the same directory on the filesystem /var/lib/docker/volumes/sentry-data/_data.

I have no idea what else I should check. I’m almost sure everything is set up correctly. But apparently I missed out something.

mkormos · December 21, 2020, 8:25am

Does anyone have a clue what might be a problem? Should I upgrade something? Or is there a helpful log file that I should look at?

Does the configuration presented above look reasonable or did I miss something?

Thanks in advance for help!

kamilogorek · January 13, 2021, 12:29pm

Hey there. In your first post you say that sourceMappingURL is pointing to a specific path:

However, in the JSON provided, you can definitely tell that it’s not the case:

All abs_path in frames are pointing to external sources, like http://owtest.example.com/ng-maps/js/12.e13162ee90fd43b4654a.js.map which is most likely the issue.

Because every sourceMappingURL is using / as the first character, it’s always trying to map using the domain where the error happened.

However, without access to the event page, it’s very difficult to tell what went wrong, and from what I see you are using on-premise, which also makes it slightly more complex, as it adds another layer where it could break.

mkormos · January 14, 2021, 7:09am

Thank you for your reply. I checked our installation again and there is indeed the following line in the 12.e13162ee90fd43b4654a.js file.

//# sourceMappingURL=12.e13162ee90fd43b4654a.js.map

But "post_context" somehow contains "/ng-maps/js/" when I emit an error.

I cannot provide you access to the server, but I will investigate why the abs_path and post_context does not look correctly.

Could you please tell me, what content is expected in "filename", "abs_path" and "post_context"? Should there be something like this?

"abs_path": "~/ng-maps/js/12.e13162ee90fd43b4654a.js",
"filename": "~/ng-maps/js/12.e13162ee90fd43b4654a.js",
"post_context": [
  "//# sourceMappingURL=12.e13162ee90fd43b4654a.js"
]

Maybe, I could rewrite frames and “fix” them with Pluggable Integrations for Node.js | Sentry Documentation

kamilogorek · January 14, 2021, 1:59pm

I think the best way to understand the whole flow is go through the code itself:

github.com

getsentry/sentry/blob/d0b593096996f0e368ebe1cf67a63e442c2fec7a/src/sentry/lang/javascript/processor.py#L610


def handles_frame(self, frame, stacktrace_info):
    platform = frame.get("platform") or self.data.get("platform")
    return settings.SENTRY_SCRAPE_JAVASCRIPT_CONTEXT and platform in ("javascript", "node")
def preprocess_frame(self, processable_frame):
    # Stores the resolved token.  This is used to cross refer to other
    # frames for function name resolution by call site.
    processable_frame.data = {"token": None}
def process_frame(self, processable_frame, processing_task):
    """
    Attempt to demangle the given frame.
    """
    frame = processable_frame.frame
    token = None
    cache = self.cache
    sourcemaps = self.sourcemaps
    all_errors = []

You can also take a look at fetch_sourcemap => fetch_file => fetch_release_file pipeline, as this is how files are fetched for the sourcemaps resolution.

github.com

getsentry/sentry/blob/d0b593096996f0e368ebe1cf67a63e442c2fec7a/src/sentry/lang/javascript/processor.py#L225


def get_release_file_cache_key(release_id, releasefile_ident):
    return "releasefile:v1:%s:%s" % (release_id, releasefile_ident)
def get_release_file_cache_key_meta(release_id, releasefile_ident):
    return "meta:%s" % get_release_file_cache_key(release_id, releasefile_ident)
def fetch_release_file(filename, release, dist=None):
    """
    Attempt to retrieve a release artifact from the database.
    Caches the result of that attempt (whether successful or not).
    """
    dist_name = dist and dist.name or None
    releasefile_ident = ReleaseFile.get_ident(filename, dist_name)
    cache_key = get_release_file_cache_key(
        release_id=release.id, releasefile_ident=releasefile_ident

If this won’t help, you can take a look at Pluggable Integrations for JavaScript | Sentry Documentation // sentry-javascript/rewriteframes.ts at 53e1df949cfa9ba0b4da6707f08246a8b2d2dee6 · getsentry/sentry-javascript · GitHub and try to use it instead, as it should give you a complete control over exception file paths.

mkormos · January 19, 2021, 9:43pm

Thank you for the advice. I will check the source code and debug it if necessary.

system · April 19, 2021, 9:43pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.

Topic		Replies	Views
Source mapping not working with existing artifacts	1	2701	September 12, 2019
Source code not found on JS files On-Premise	18	6602	May 10, 2021
Sentry Issues is Not Referring to Offline Source Map On-Premise	8	2974	December 28, 2020
Can't use sourcemaps/artifacts	18	6846	March 30, 2017
Offline sourcemaps not used On-Premise	6	6307	February 19, 2019