Is it possible to disable source mapping at Layer0?

Issues
,
#1

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

image
image1152Ă—397 51.9 KB

#2

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?

#3

I found this comment in withLayer0.js code

image
image1867Ă—1016 236 KB

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?

#4

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
#5

P.S., @jillesmc - excellent spelunking, but no, the code under that comment is not it. :slight_smile:

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
#6

@lobsterkatie Thank you for the explanation :wink:

Maybe @patrick.saweikis could help us to bring some attention to this thread :slight_smile:

#7

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
#8

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

  1. Run layer0 build
  2. upload source-maps to Sentry, then clear all *.map files from .layer0/lambda subdirectories
  3. Run layer0 deploy --skip-build to deploy to Layer0

Please let me know if that helps,
Adrien

#9

Hi @adrien-kiren,
thank you for the answer. :slight_smile:

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.

#10

@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:

  1. the build with source-maps
  2. upload to Sentry
  3. 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.

#11

@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?

#12

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!