bleak lintel
I'm running a GraphQL server on top of an Express app.
I followed the sourcemaps wizard to modify the build script so it will inject and upload the sourcemaps.
When capturing an error, I don't see context lines in the stack trace.
Clicking the Unminify code button shows I'm missing some steps (see pic) but it's not clear to me what I should do next.
Help would be appreciated.
This is how I see the stack trace frame
bleak lintel
Can't see context lines in the stack trace frame
gusty lichen
Hi, can you show your build script in package.json please? Are you deploying the files that come out of this?
bleak lintel
@gusty lichen Thanks for replying.
I run this script after the actual build (it's the final step of the npm run build script)
// Login to Sentry
execSync(`sentry-cli login --auth-token ${process.env.SENTRY_AUTH_TOKEN}`, { stdio: 'inherit' });
// Inject and upload sourcemaps
execSync(`sentry-cli sourcemaps inject --org ${process.env.SENTRY_ORG} --project ${process.env.SENTRY_PROJECT} ./dist`, { stdio: 'inherit' });
execSync(`sentry-cli sourcemaps upload --org ${process.env.SENTRY_ORG} --project ${process.env.SENTRY_PROJECT} ./dist`, { stdio: 'inherit' });
What do you mean by "deploying the files"? uploading them to Sentry?
I can see in my account that the sourcemaps have been uploaded successfully
gusty lichen
That looks okay to me so far. By deploying I mean, after you build your app and this script runs to upload the source maps, are you then deploying the built files that come out of this build directly or are you maybe building them again somewhere else and deploying those?
bleak lintel
I'm at a preliminary stage where I'm exploring Sentry locally at the moment. I'm not deploying anything at the moment. I run the build locally (the sourcemaps are being uploaded at this stage) and then run the server using the built files (again, locally).
Note that after I upload the sourcemaps I delete them (the .js.map files) and only then run the server. I got this suggestion from https://docs.sentry.io/platforms/javascript/sourcemaps/uploading/typescript/ doc.
bleak lintel
@gusty lichen I tried it again now and it seems to work. Not sure what I did differently though...
bleak lintel
@gusty lichen I have another issue though. When the DB raises an error, the local variables are not included in the stack trace frame. This is what I see.
I already created a MRE repo for another bug I had recently which @boreal drum was able to help me with.
I modified the repo to include a testDbError query that reproduces the issue.
So currently, the testSentry query works as expected and does retrieve local variables but testDbError doesn't.
bleak lintel
@gusty lichen @boreal drum Can you plese have a look? I would really like to introduce Sentry to my company but this issue blocks me..
gusty lichen
hey roinr, sorry I missed this. Thanks for the MRE, we'll have a look.
bleak lintel
@gusty lichen Any luck with that?
bleak lintel
Anyone can have a look at this please?
boreal drum
hey @bleak lintel sorry for the delay, I'm taking a look at this now!
boreal drum
it seems like the way the knex orm is designed is obsfuscating the captured exception
it means we cannot reconcile it with the local variables
bleak lintel
Thanks!
Thats a bummer..Is there another way I can use knex to make it work?
boreal drum
not sure, I'm investigating this with a colleague to see if there is a workaround
cc @random spoke
bleak lintel
awesome thanks!
bleak lintel
@boreal drum Do you know what exactly is problematic with the error that knex throws? Will it help to manipulate it somehow before passing it to Sentry?
boreal drum
Actually this is a good point. I wonder if reconstructing the error is helpful here. Let me try that
boreal drum
yeah that doesn't work 😦
The issue is https://github.com/knex/knex/blob/9bd12999907436c2ef51f786df09a9a7e8931cca/lib/builder-interface-augmenter.js#L28-L41
because they are rewriting the stacktrace, but then rethrowing the original error instance we can never link the local variables correctly
bleak lintel
Oh I see..can you explain exactly what's interfering the local variables linkage process in this case (maybe share a link to the relevant sentry code)? Is it just a matter of how the stack trace (returned by Knex) is structured? If so, how should a valid stack trace look like?
bleak lintel
Manipulating the stack trace doesn't work because sentry is matching the stack trace with the stack trace of it's own debugger, right?
bleak lintel
From what I understand, this line fails to match function name from DB error stack trace with function name from the inspector's track trace.
So I guess my best option is to listen on query-error events and inject query bindings into the error instance and then add them as extra when capturing the error with sentry..