Sentry: How to resolve source-map from sourceMappingURL by native (electron) app?

[jakubzitny]

Hi, regarding the need to name release artifact correctly according to URL it is served from:

We're using Electron to create web-based native app and its content is not available from no URL. I suppose it'd be best for Sentry not to resolve relative sourceMappingURLs. This way we'd be able to just upload a app.js.map and the app would have //# sourceMappingURL=app.js.map in app.js.

Otherwise I am not sure how to name the source map artifact in a release. I've tried to put the full local path as well. The one found at the issue page under the exception section - it looks like this /path/to/app/app.js. But that is different on every computer the app is launched from and it didn't work anyway.

So what should we do if we want proper Exception/Error stack without the minified nonsene? Any ideas?

From sourcemaps documentation: "Sentry will resolve sourceMappingURL relative to https://example.com/dist/js/ (the root path from which app.min.js was served). You will again need to name your source map with the full URL: https://example.com/dist/js/app.min.js.map."

[benvinegar]

It's likely looking for file:///app.js.map, but to see for sure what value Sentry is resolving sourceMappingURL too, we recommend opening up the raw JSON view of your event (there's a big link labeled "JSON" at the top of the event in Sentry's UI).

In that JSON, you'll see resolved values for filename and sourcemap for each frame. Note that if Sentry cannot reach the source file, it cannot find the sourceMappingURL directive, and will not look for a source map. You need to upload both the source file(s) and source map.

Sentry will also show an error at the top of each event when it fails to download a file (or access a file from release artifacts), which you can expand to see what URL it's trying to reach:

[benvinegar]

Keeping this ticket open because I'm planning to add something to docs about debugging source map issues.

[jakubzitny]

Thanks for your response here and on support as well.

I've created a sample repository with this problem here and tried several possible names for artifacts at hosted sentry. None of them worked though, please have a look if you can @benvinegar.

1.

• map file is uploaded as app.js.map
• release 0.0.7
• issue

2.

• map file is file:///app.js.map
• release 0.0.8
• issue

3.

• /Volumes/path/to/app.js.map
• release 0.0.9
• issue

4.

• file:///Volumes/path/to/app.js.map
• release is 0.0.10
• issue

5.

• i've fake named the source map http://example.com/app.js.map (also in app.js's comment)
• release is 0.0.12
• issue

Actually there is also no error about files it is trying to reach in any of the cases. And also the advice to look into the raw JSON doesn't really help because in JSON there is only the same comment as it's in the minified file at the end. And we know that.

I am going to look into an idea of normalizing the name before sending the stacktrace to Sentry.

[benvinegar]

Just checking – you're running Sentry 8.x?

[benvinegar]

Also, are you uploading your source files? Everything so far seems to be about source maps. If Sentry cannot read your source file bundle (e.g. app.min.js or whatever Electron produces), it cannot read sourceMappingURL.

Most of the source map documentation in our docs assumes that your JavaScript files are publicly reachable (i.e. when it's downloaded and parsed by a browser), which is why we don't document "oh btw your source files need to be reachable" much.

[jakubzitny]

Yeah, now I am testing it at app.getsentry.com which is 8.2.0.dev0. And yeah I am uploading app.min.js and the app.min.js.map as artifacts for each release. That should be enough, right?

I have also just tried to normalize the filenames in exception object that's being sent to Sentry, inspired by this like this:

var clientConfig = {
  release: pJson.version,

  dataCallback: function(data) {
    var normalize = function(filename) {
      splitArray = filename.split("/");
      return splitArray[splitArray.length - 1];
    };

    data.exception[0].stacktrace.frames.forEach(function(frame) {
      frame.filename = normalize(frame.filename);
    })

    data.culprit = data.exception[0].stacktrace.frames[0].filename

    return data
  }
};
var ravenClient = new raven.Client(sentryDsn, clientConfig);

So it's not sending no file:/// nor /full/path/to/file.js, only the filename. However it is still not working. I am starting to think the problem is somewhere else, but I am not even sure how it's supposed to look like. Would that be a big trouble for you to check the issue out at getsentry? Artifacts are there, no error message, no nothing.

[mattrobenolt]

@jakubzitny Are you using raven-node and not raven-js? For your events being set to us, the "platform" key is "node". See: https://app.getsentry.com/avocode/test/issues/112744530/events/3989627958/json/

So because of this, fundamentally, we're not even attempting to apply any sourcemapping.

Also the code you posted seems to suggest it's raven-node as well, since new raven.Client() is not how you'd do it in raven-js.

[jakubzitny]

@mattrobenolt this is probably the case :)

But why should I use raven-js? I am using node.js (that's what Electron uses, it's not web, there are requires, etc.), that's why I used raven-node. Node is also sourcemapping candidate I think.

So what should I do? Should I use raven.js? Is it possible under node? Or should I just manually set the platform to something else than node?

[mattrobenolt]

This is an area I don't have an answer for, and we don't have direct experience with Electron for me to push you into any direction, so I'll just lay some information out here:

raven-node does not work with sourcemaps. tbh this is the first time I've ever heard of anyone doing this, since there's not really a reason to run server side code through a minifier that I'm aware of. So not sure why this is the case for Electron why it'd be minified in the first place.

raven-node reads files from the local file system, so this behavior is 100% skipped on the backend in Sentry since it assumes everything was done correctly, and doesn't even look for a sourceMappingURL.

raven-js on the otherhand is handled explicitly on our side for code that has the platform "javascript", where we attempt to fetch urls and map things up.

Sourcemaps are treated as urls in our system (hence the initial confusion with file://, etc because they are always resolved by browsers. In the case of raven-node, we don't even have urls to work with, so this entire path would fail on the backend. At minimum, we'd expect file paths to at least be file://, but raven-node does not send file paths in that format anyways.

So I'm not sure what we can do here without some good efforts. I'd like to understand more about why the code is being minified and whatnot anyways for node. If this is a normal thing, it's possible then that we just need to support sourcemaps for node, and not just browser js. If that's the case, then this has nothing to do with Electron at all, and we can summarize as just "sourcemaps for node". But I'm failing to understand why this case exists. It's likely that I'm just old and don't work with these tools. :)

[mattrobenolt]

Oh, and to answer your question, raven-js won't work under Node since it relies on XHR and makes other browser assumptions.

[jakubzitny]

Thanks for the comment. So the case is that Electron is a maybe stripped-down browser but it still uses node for everything. So when I write an Electron app and I want to distribute it I may still want to minify all the javascripts that are packaged into the final native app. The result is smaller app and also the code, which is accessible by user, is harder to read.

electron intermezzo:
Electron has two "main" parts — main an renderer process. One is just running the "setup" part for the whole "web-based" app and the renderer just renders htmls, csss and javascripts. So to simplify it: the basic Electron app is just an index.html that loads some javascripts and works. However!, inside that index.html we can use require. So it is not really browser, but it is a "node". At first I was suprised that you guys have javascript and node clients separated, since it is quite possible to write it for both.

All in all, I think you should definitely support minification under node, especially for Electron. But the minification can of course be desired for a server-side app or Node-Webkit.

I can look at raven-js and raven-node code and maybe help you guys with it, maybe I can come up with a simple solution. The easiest I think would be supporting the raven-node on your backend, so you would not just deny everything labeled with platform: node of sourcemapping. You can tell me what do you need for sourcemapping and raven-node can just provide it. The source file names can be normalized, so you'd get everything you need and just pair it with uploaded artifacts and that's it.

What do you think?

Also, can you please tell me what is the platform for web with raven-js? I will try to just lie to you from raven-node..

[jakubzitny]

So I tried replacing the platform with javascript and now it is at least showing me some errors:

[mattrobenolt]

Before we dive down that path, does Electron have access to XHR? I'd expect that we could/should make raven.js work here. We use raven-js for React Native already. For the most part, raven-js would provide all of the same functionality, if not more.

[jakubzitny]

Electron (Node in general) has plenty of libraries for this kind of functionality at NPM. There are some libraries for XHR, however, afaik most of the time you use something more robust (like request). You can package the node modules from NPM for browser/web with browserify. But then you don't care about Same Origin Policy in Node.. so the choice would have to be made, probably using node's xhr-like library, but I'm not sure about that now.

[dcramer]

Only going to comment briefly, but I'm all for supporting sourcemaps for Node.js (rather than forcing browser JS fundamentals on Node).

[jakubzitny]

So actually I was just told (I should've known) that you can even use the Javascript client in Electron. You just have to use it from the index.html file that's the content of Electron's BrowserWindow. So I add raven-js via script tag and then I just use the Raven global in the rest of the code. Now we have to find out whether the filename normalization works and how many source files we need to upload.

Also for general node vs javascript raven support, I think you would be able to allow the same functionality from raven-node as raven-js has, we just have to find out the filename stuff.

[jakubzitny]

So I tried it with raven-js in Electron's index.html, however it only sends the index.html in the trace, so the results are pretty useless and there is probably no sourcemapping going on anyway. (but it works without artifact errors, once I uploaded inedx.html):

EDIT: However, if I don't use require('./app.min') in the index.html but instead I use a <script> it seems to be working :smile:

Before I had

<body>
  <h1>Hello World!</h1>
  We are using node <script>document.write(process.versions.node)</script>,
  Chrome <script>document.write(process.versions.chrome)</script>,
  and Electron <script>document.write(process.versions.electron)</script>.
</body>
<script type="text/javascript">
  window.onload = function () {
    require('./app.js'); // minified
  }
</script>

Now I have working:

<body>
  <h1>Hello World!</h1>
  We are using node <script>document.write(process.versions.node)</script>,
  Chrome <script>document.write(process.versions.chrome)</script>,
  and Electron <script>document.write(process.versions.electron)</script>.
</body>
<script type="text/javascript" src="./app.js"></script>

[benvinegar]

@jakubzitny – I think it actually was working, as in, require was not defined (it is likely minified to qwe in your bundled script, source maps unfortunately can't translate back the error message string itself).

So – I see you solved this by using <script> instead. Does that mean there's anything else to do here? We're probably going to investigate source maps via raven-node anyways.

[jakubzitny]

@benvinegar hey, so yeah I got that working with <script> so if I hack it around with raven-js it seems to be working. If you want you can close this issue and start a new one regarding the source-map support for node.

Note that index.html on Electron understands require() function. I didn't really understand the first part of your last comment, because require was defined it is just not able to follow node-ish requires or something like that.. since they do not have full filenames not even the ".js" extensions like linked scipts in <script> tag. I am not sure though.

I think there might not be that many problems with making the main raven-js library work on Node. I'd just use base filenames of the local files for names of artifacts and add a the dataCallback I implemented into the library when on Node (so the library sends only the filenames, not whole paths).

You might wanna add a note about "Electron" to Javascript Integrations in your docs. You are probably thinking about it already.

Good luck.

[mattrobenolt]

I just came across this for node sourcemaps: https://github.com/evanw/node-source-map-support

From my brief, 10 seconds of reading the README, it seems to imply that this will modify the stacktraces themselves and apply the sourcemap on the server, so in theory raven-node would work if you had this.

I think this is similar to how we support stacktraces properly for coffeescript, since the coffeescript stuff parses it's own stacktraces somehow, and we read them as any normal one just fine.

[jakubzitny]

I am not sure we need it since we have all sourceMaps already. Webpack generates the coffee -> js for us with all source maps. There is no magic in it actually. We are then sending the sourceMaps to Sentry and Sentry should be able to understand as it is. It works for us already with raven-js, with normalizing filenames and faking "javascript" target. So to make it work with raven-node I think you just need to do these and that's it.

[dcramer]

I agree that we should just support sourcemaps for Node on the server. It just comes down to prioritization at this point. There's a few caveats with our current implementation that we'll need to work around (e.g. explicitly forcing it to not request non-URLs).

[greatelv]

Can i resolve the fetch issue using release artifact ?
Our product is none hosted native web-app such as electron
I already uploaded source file in that release artifact but It was not work well.
In your link (https://docs.sentry.io/clients/javascript/sourcemaps/)
This guide only said about .map file (not source file).

[greatelv]

It is status of release artifact
Any ideas?

[danii1]

Has anyone had luck to make sourcemaps work in Electron app?
I'm getting errors such as
"Source code was not found for file:///Users/{user}/{path}/{name.app}/Contents/Resources/app.asar/renderer.js".

Including ~/ in the names of the uploaded artifacts doesn't help and it solves problem with multiple protocol/hosts, not paths.

[jakubzitny]

Yes, we are modifying the filenames in dataCallback in Raven config like this:

dataCallback: (data) ->
  if data.exception
    data.exception.values[0]?.stacktrace?.frames?.forEach (frame) ->
      frame.filename = "/#{path.basename(frame.filename or '')}"
    data.culprit = data.exception.values[0].stacktrace.frames[0].filename

  return data

[dimitarnestorov]

@benvinegar This needs a close since https://github.com/getsentry/sentry-electron exists

[jakubzitny]

Nice, good to know. Yeah, this is definitely irrelevant as of sentry-electron. I will give it a try at some point 👍