Hey guys.
I have a problem that I believe is caused by some specific configuration of how the deployment of Nextjs applications are done on Layer0.
We use the sentry.io platform to do bug tracking in our application and the way this is done requires us to send the source maps at build time to Sentry, so when an error happens Sentry is able to to do the source mapping and point out the exact piece of code that is causing the error.
However, we are not able to use this platform as much as possible because, according to Sentry engineers, the source mapping process is already being done by Layer0, preventing Sentry from being able to correctly identify the location of the error.
My first guess was that source mapping was being caused by the configuration layer0SourceMaps
But even forcing it to be false
, the stack trace is showing the Typescript files
Hey @howie.ross I found another post that you talked about source mapping.
Could you help me to understand what is happening here? pls .-.
Is it possible to disable this source mapping behavior?
I found this comment in withLayer0.js code
I suppose it is consuming the source maps, even when I don’t pass layer0SourceMaps: true
.
Could you confirm that for me?
Are you using the flag --enable-source-maps
in NODE_OPTIONS?
Hey, there, Layer0 devs - Sentry engineer here.
I’ve been helping debug this from our end, and while initially I had suggested trying to disable the Layer0 sourcemaps (which would work to solve Jilles’ problem with Sentry), it occurs to me that there’s a much better way.
It would in theory only take a one line change from each of us - y’all at Layer0 in your error handling code and us in our JS SDK code - and I’m happy to make that change if you all are also on board.
Right now I presume you’re doing something like this (pseudocode):
try
do something which blows up
catch err
sourcemappedError = applySourcemaps(err)
log(sourcemappedError)
throw sourcemappedError
because when our SDK gets ahold of the error, it’s in its already-sourcemapped form. But if you all would be willing to do this instead:
try
do something which blows up
catch err
sourcemappedError = applySourcemaps(err)
sourcemappedError.originalError = err
log(sourcemappedError)
throw sourcemappedError
then we could look for and capture the non-sourcemapped exception, without changing the layer0 UX at all (logged errors would still be sourcemapped, for example, which they obviously wouldn’t be if Jilles were able to disable sourcemapping).
What do you think?
1 Like
P.S., @jillesmc - excellent spelunking, but no, the code under that comment is not it. 
That just causes webpack to emit sourcemaps. Even if Layer0 didn’t set that, our SDK would, so that sentry-cli
has sourcemaps to upload to Sentry. This change would need to be made on the Layer0 servers, such that either the sourcemaps were never applied or, as I’m suggesting above, that they were applied but access to the original error preserved.
(The node flag, OTOH, if set on the Layer0 servers, might be relevant here. Still, if there’s a way to avoid turning off the sourcemaps, I think that’s preferable.)
1 Like
@lobsterkatie Thank you for the explanation 
Maybe @patrick.saweikis could help us to bring some attention to this thread 
Hi @jillesmc,
We have created a ticket around this to have one of our engineers investigate the issue you are running into (XDN-13838). We will provide an update here once there is more information.
Thanks,
Tristan
1 Like
Hi @jillesmc ,
Thank you for your message.
To answer your questions:
Yes, we run all our serverless functions with --enable-source-maps
flag, so if you publish a deployment containing source-maps, they will be loaded.
Setting layer0SourceMaps
to false only “not enables” the generation of source-maps file but it does not disable it if it has been manually enabled, does not affect the NodeJS flag or prevent existing *.map
files from being uploaded.
If I understand correctly you need those source-maps files to be generated to send them to Sentry but at the same time they should not be sent to layer0 as this would enable sourcemaps and conflict with Sentry
Until we can provide a better solution for that use case, one quick workaround would be to run this in 3 steps, with layer0SourceMaps: true
- Run
layer0 build
- upload source-maps to Sentry, then clear all *.map files from
.layer0/lambda
subdirectories
- Run
layer0 deploy --skip-build
to deploy to Layer0
Please let me know if that helps,
Adrien
Hi @adrien-kiren,
thank you for the answer. 
I believe there is an issue with this solution because I need to build my app using the environment variables from Layer0.
The command layer0 build
has no parameter to set the environment and pull the env variables and secrets.
@jillesmc indeed, this is only available with deploy command… no easy way out of this I’m afraid.
Maybe with some environment variables you can manage to run:
- the build with source-maps
- upload to Sentry
- run the deploy - including build - without source-maps? setting layer0SourceMaps to false, and disabling Sentry which seems to enable source-maps too.
@lobsterkatie
Regarding your suggestions, we don’t really apply source-maps ourselves, NodeJS is doing it for us. So I’m not sure we could expose both traces easily.
We’d rather give users more fine-grained control over using source-maps or not.
@adrien-kiren in this case I prefer to see more fine-grained control over source mapping on Layer0. I’m unable to build the application without the secret variables from Layer0 environments.
@lobsterkatie Do you have any idea?
Ah, yes, right - I see now. Thanks.
Nothing that’s actually working yet. I did play around with it, trying to emulate what node does when it creates the original stack before it’s sourcemapped (see: node/events.js at master · nodejs/node · GitHub), but I ran a quick test and at least so far it’s not working. I’m sure there’s some subtlety I’m missing…
Of course, in a perfect world, Node would do exactly what I was hoping Layer0 could do - give us access to the “before” as well as the “after.” Though you’re the first to bring this up, I’m sure there are other situations in which this could be a problem, so I went ahead and filed a feature request. I’m not holding my breath, but you never know!