Source code was not found for index.js

[guischdi]

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other:

Version:

4.4.1

Description

The following event capturing code will produce an error in Sentry while parsing the event: Source code was not found for /.../index.js

const Sentry = require('@sentry/node');

Sentry.init({ dsn: 'https://5d29[...]58f@sentry.io/13[...]6' });

(async () => {
  const sentryEvent = await Sentry.Parsers.parseError(new Error('Test'));
  Sentry.captureEvent(sentryEvent);
})();

Here is how the event looks like in Sentry:

[kamilogorek]

Can you post a direct link to the event?

(you also missed some paths in the stacktrace screenshot you masked earlier 😅)

Any particular reason why you don't use Sentry.captureException directly, but rather want to create your own event?

[guischdi]

Yepp, this is the event: https://sentry.io/share/issue/e2c8d20b66d2406cb32c540d87654b4a/ (slightly modified to not publish our dsn)

The reason, why I use Sentry.captureEvent() is the following: I'm maintaining a hapi plugin that captures error events thrown by hapi route handlers (enriched with request data). See: hapi-sentry ./index.js#L41-L67

[kamilogorek]

@guischdi the reason why you get this error is that local file paths are not reachable to remote servers.
Sentry is trying to fetch and resolve /something/local/src/app.js and read the source-code from it to provide better error mappings (it works in the same way with sourcemap files).

To upload your files, you can use our CLI https://docs.sentry.io/cli/ or Webpack plugin https://github.com/getsentry/sentry-webpack-plugin

Here are some old docs on source maps, but the concept is the same for new SDK https://docs.sentry.io/clients/node/sourcemaps/ (it all applies in the same way to your current issue).

There's also an existing integration you can use to rewrite paths in every frame https://github.com/getsentry/sentry-javascript/blob/master/packages/core/src/integrations/pluggable/rewriteframes.ts

So for example:

Sentry.init({
  dsn: "https://363a337c11a64611be4845ad6e24f3ac@sentry.io/297378",
  integrations: [new Sentry.Integrations.RewriteFrames()]
});

Will change /something/local/src/app.js to app:///app.js (app:/// is our internal prefix), so when you upload app.js to your sentry release artifacts, it will be read correctly without a need to fetch external files.

Basically what you need to do is:

• set a release in init call
• upload your sources to the same release in the Sentry
• make sure that frames in errors you catch correspond to those from your upload files

Hope it clears some things for you. Feel free to ask anything if you need more help.

[guischdi]

Hi @kamilogorek
Thanks for your detailed answer.

Did I get it right: The common way to have a stack trace of a Node.js application show up in Sentry is to upload the files of each release via RewriteFrames integration or manually? If so, how comes that the stack trace on captureException/catch-all is shown and no 'source code not found' error is triggered.

I tested how throwing an Error in a node_modules lib works. The error gets reported correctly including source code even from the lib. See https://sentry.io/share/issue/2b95ecb13ce24227b2184b2561e4f6e3/

So why does this work with captureException and fails with captureEvent?

[kamilogorek]

@guischdi can you past full link to both events? Not shareable ones? I can access them through admin permissions.

Also, I'll be out of office for the next 3 weeks, so I'll try to get back to this one when I'll come back.

[guischdi]

@kamilogorek

• this is the captureEvent Link
• this is the captureException Link

Thanks for having a look at this!

[tinovyatkin]

@kamilogorek Do you mean I need to upload whole node_modules folder for every release too? Why @sentry/node when running on the server and have all this sources available just can't upload needed files with error report?

[mieszko4]

I confirm that after setting frames integration and basically uploading whole node_modules resolves this issue to me. But the process of uploading so many node_modules files is extremely slow.

I believe the solution to this is either:

1. allow by sentry to upload a .tar of entire release
2. compile node project to single .js and .map and deploy and upload only these two files.

Also, I was having problem with source maps that referenced original .ts file that was not in the node_modules npm package - maticzav/graphql-middleware#159

[guischdi]

@kamilogorek Any news on this issue?

[acidoxee]

I can also confirm that rewriting frames was the solution for us.

Our case is a bit different, we were trying to make sourcemaps work, but the minified file was always the one used by Sentry. For the corresponding release, we are uploading minified files as well as associated sourcemaps. It appears Sentry was not finding the sourcemap, and was defaulting to the minified file (which is still hosted at the same path than the sourcemaps though).

We just added new Integrations.RewriteFrames() to the integrations' key to Sentry's init, and sourcemaps started to be picked up for every new issue.

[guischdi]

It's good to know, that the RewriteFrames integration and uploading node_modules seems to solve the problem. But first (as @mieszko4 already mentioned), uploading so many files is quite annoying. And furthermore my initial finding was,

that the stack trace on captureException/catch-all is shown and no 'source code not found' error is triggered

So the following question remains open:

So why does this work with captureException and fails with captureEvent?

Or more precisely: One can simply capture an error via captureException without problems, but for capturing via captureEvent an upload of all files (RewriteFrames integration or manually) is required to prevent the "source code was not found"-error. Is this a bug or intended, @kamilogorek?

[kamilogorek]

@guischdi sorry for such a late response. I lost a track a bit. Can you refresh my memory what's going on here and provide some sample events?

[guischdi]

@kamilogorek
Yes, our problem is:

• captureException works just fine, even if a node_module throws an error; see this test exception
• captureEvent give sentry hick-ups: error encountered while processing this event: [...] Source code was not found; see this test event

[kamilogorek]

@guischdi just to confirm, this is raw node js file right? no webpack, no compilation, no source maps. Just one index.js file with 2 different calls on different lines? Can you provide the content of this file if possible?

[guischdi]

@kamilogorek
Yes, raw nodeJS. Have a look at the second issue I linked above. You already see all 13 lines of the index.js there.

[kamilogorek]

@guischdi we are investigating why it's behaving like this (2 consecutive frames with the same url triggers this). In the meantime, you can turn off "Enable JavaScript Source Fetching" in your project's settings, eg. https://sentry.io/settings/kamil-ogorek/projects/testing-project/
It's node app, so there's no point in doing that.

[guischdi]

@kamilogorek Ok, I turned off the "Enable JavaScript Source Fetching" setting and triggered another error. But still 1 error encountered while processing this event: [...] Source code was not found (see this issue)

[kamilogorek]

Odd, that works for me just fine. Anyways, we'll try to investigate why that happens, although I cannot promise when it happens, as it's not major issue preventing anything from working. Will keep you posted!

[msaspence]

@kamilogorek any news on this?

For me the issue view reports the source code as missing a few files, but they are all present and viewable under the stack trace.

[simontong]

I'm running Sentry self-hosted and using @sentry/node 5.4.3

Heres my code:

// file: <path>/code/cli
const Sentry = require('@sentry/node');
Sentry.init({ dsn: process.env.SENTRY_DSN });
function test () {
  throw new Error('test');
}
test();

I'm also getting this error:

And here is the stack:

Error: test
  File "<path>/code/cli", line 10, col 9, in test
    throw new Error('test');
  File "<path>/code/cli", line 13, col 1, in Object.<anonymous>
    test();
  File "internal/modules/cjs/loader.js", line 1063, col 30, in Module._compile
  File "internal/modules/cjs/loader.js", line 1103, col 10, in Module._extensions..js
  File "internal/modules/cjs/loader.js", line 914, col 32, in Module.load
  File "internal/modules/cjs/loader.js", line 822, col 14, in Module._load
  File "internal/modules/cjs/loader.js", line 1143, col 12, in Module.runMain
  File "internal/main/run_main_module.js", line 16, col 11, in null.<anonymous>

[LukeXF]

I'm also running into this issue Source code was not found

[kamilogorek]

@LukeXF can you provide a link to an affected event?

[lobsterkatie]

The reason you can see source context (which is to say, code above and below the line in question) even though you're getting "can't find source code" errors is that in the SDK, before we send the event, we record this information as part of processing the stacktrace. The error is coming from the server also trying to fill in that information.

That's a bug on our end, though, because we're not actually expecting you to upload node_modules with every release (for node apps; for browser apps you're likely bundling/minifying anyway). Should be fixed by getsentry/sentry#17538, which will get deployed in a few hours.

Once that fix lands, can anyone who's commented here please let us know if you still have problems/questions, and what they are? Happy to re-open this if needed.

[guischdi]

Hi @lobsterkatie
tested it again, with the following snippet (stripped from the current README on npm):

const Sentry = require('@sentry/node');

Sentry.init({ dsn: process.env.DSN });

(async () => {
  Sentry.captureException(new Error('Good bye'));
})();

Unfortunately we still get the Source code was not found Error on https://sentry.io/share/issue/0247fe07741c4e358089461f113cef42/
Is the fix you introduced yesterday already deployed?

Also tested with the current v4.x.x version (v4.6.6) and the latest release (v5.14.0) of @sentry/node.

[kamilogorek]

@guischdi you didn't upload any artifacts, nor included a release in your configuration.

Please follow the docs first: https://docs.sentry.io/platforms/node/sourcemaps/

[guischdi]

@kamilogorek

in the SDK, before we send the event, we record this information as part of processing the stacktrace. The error is coming from the server also trying to fill in that information.
That's a bug on our end, though, because we're not actually expecting you to upload node_modules with every release

If I understood @lobsterkatie right in that point (quoted above), I should not need to upload the code. In the issue link you can see all the source code context needed to understand the issue (in this case all the source code of the script). So this seems to be recorded properly. I don't think I need to upload/serve sourcemaps (as your link proposes), because it's an un-minified plain Node.js program.
I think the only issue left, is the error being displayed although the context ist properly provided. The server seems to not recognize that it does not need additional uploads from my side. (Am I getting that right @lobsterkatie ?)

[lobsterkatie]

@guischdi The file it's looking for is from your app, not from node_modules, so the change I made (to more successfully exclude 3rd party code) wouldn't apply here.

The reason we try to process source maps for node apps is that while it's true that the code is very likely not minified, it could quite easily be transpiled (if it were written in typescript, for instance), and so we'd need source maps to display the code as written rather than the output from babel.

[guischdi]

Ok, so this looks like a UX bug to me. In my opinion it should (at least for Node.js projects) be only a warning and it must not say Source code was not found but something like Source maps were not found. This would have prevented an issue with a history of more than a year ;)
If you want you can reopen this issue as a report for whoever works on the frontend/display part, or just leave it closed and report this misunderstanding to them. Thanks a lot for finally clarifying this!