sentry-electron: Using source maps, not showing original code

@dimitarnestorov, thanks for providing more context. From what you are saying, it seems you are having two issues.

Let’s start with JavaScript code context and source maps. It seems that you’re uploading the right source maps, but they are missing the /build/ path component. I suspect this is why Sentry is not able to match them up correctly. I’m not sure how you’re uploading the source maps right now, but you can try to:

• Run the CLI command from the parent folder
• Set the --url-prefix option to ~/build/ as described here
• Configure the urlPrefix option if you use our webpack plugin

After that, the paths of your source maps on the releases page should match the ones in the issue exactly (or actually, you should start seeing the resolved source files). Let me know if that does not work, as I’m currently investigating an issue with source maps in renderer processes.

Regarding native debug information files (Electron symbols). You do not need to upload Electron symbols for JavaScript support, they are only required for native crashes. Unfortunately, even if you could upload those symbols, 8.22 does not yet have the capability of dealing with native crashes. Let’s continue that discussion in getsentry/sentry#7804.

Thanks @kamilogorek for the explanation. You were right, I need to upload both the .js and .js.map files for it to work. I didn’t upload them since on the web version of our app it worked without doing so, that made me think that sentry doesn’t need them at all.

I’ve solved this problem. it is because something went wrong in the docker.

@dimitarnestorov are those all the artifacts that you upload? If so, then you missed all the source files 😃 We need a 1 to 1 js.map to .js mapping, so we can correlate them correctly.

This is how browsers work as well. What we do is we take a look at each stacktrace’s frame and pull out the culprit file, let’s say b8g7ws9024j89dfgsa.js. Then we have to either scrape it from your server (if it’s a remote url), or look for it in uploaded artifacts. When we find it, then, and only then, we can read it to determine whether it contains linked sourcemap (by veryfing the existence of the standard sourcemap suffix, eg. //# sourceMappingURL=b8g7ws9024j89dfgsa.js.map).

What most likely happens here is that we are not able to find the source file itself, so the system is not able to understand what’s it’s sourcemap file is (as there’s nothing that stops you from having a sourcecode in foo.js file and link a sourcemap from bar.js.map to it).

@dimitarnestorov are those all the artifacts that you upload? If so, then you missed all the source files 😃 We need a 1 to 1 js.map to .js mapping, so we can correlate them correctly.

This is how browsers work as well. What we do is we take a look at each stacktrace’s frame and pull out the culprit file, let’s say b8g7ws9024j89dfgsa.js. Then we have to either scrape it from your server (if it’s a remote url), or look for it in uploaded artifacts. When we find it, then, and only then, we can read it to determine whether it contains linked sourcemap (by veryfing the existence of the standard sourcemap suffix, eg. //# sourceMappingURL=b8g7ws9024j89dfgsa.js.map).

What most likely happens here is that we are not able to find the source file itself, so the system is not able to understand what’s it’s sourcemap file is (as there’s nothing that stops you from having a sourcecode in foo.js file and link a sourcemap from bar.js.map to it).

hi @dimitarnestorov as you replied this: Then we have to either scrape it from your server (if it's a remote url), or look for it in uploaded artifacts, could you be more specific about when it will look for sourcemap from the uploaded artifacts? in my case it always looks form my server, so If I deleted all sourcemaps in my server (which is recommended to do so), I cannot see the detail of error any more.

@kamilogorek I believe @chj-damon meant to mention you instead of me

Great investigation and solution 😃 This was exactly our problem too! ❤️