Scopes are leaking in NestJS requests

[sagrawal31]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/nestjs

SDK Version

9.10.1

Framework Version

Nest 10.3.10

Link to Sentry event

No response

Reproduction Example/SDK Setup

No response

Steps to Reproduce

1. Create a NestJS app.
2. Add a controller with a simple log.
3. Add a NestJS interceptor which sets tags/context/user conditionally (maybe based on some header/authentication).
4. Hit the first request, which should set some tag/context/user.
5. Hit the second request, which should not set any request and log an error to Sentry.

Expected Result

The tracked should not have any custom tag/context or user.

Actual Result

The tracked error have the tags/context/user from the previous request.

[sagrawal31]

I'm trying to reproduce this on a fresh NestJS project and couldn't reproduce it. Please don't spend time on it yet. Will keep you updated.

[Lms24]

Hey @sagrawal31 thanks for letting us know! I'll close this issue for now to maintain a clean issue feed but please feel free to ping me whenever you have a working reproduction and then we'll reopen this. Thanks!

[sagrawal31]

Thank you @Lms24. I spent my last 2 days converting my test NestJS project as similar (like wrapping to promise, calling Sentry at almost the same places, etc.) to our production code, but it wasn't helping.

So, I took a different approach. I started removing modules and code one by one from our vast production code and started testing the leak, and I'm glad I succeeded. Here is a fresh NestJS code to reproduce the same: https://github.com/letscooee/nestjs-sentry-test

Steps to reproduce

1. Clone the repo git clone https://github.com/letscooee/nestjs-sentry-test.git
2. Set an environment variable SENTRY_DSN or modify sentry.service.ts directly for the DSN.
3. Run npm run start:dev and server should be up at 3000 port.
4. Run the following requests:

# /foo endpoint will set a tag and user and capture an "Error1" issue on Sentry
curl --header "content-type: application/json" http://localhost:3000/foo

# /bar endpoint will not set any tags and user and capture an "Error2" issue on Sentry
curl --header "content-type: application/json" http://localhost:3000/bar

Expected behaviour

The second request should not leak on the Sentry request

Actual behaviour

The tag and user are leaking to the second request as well.

Workaround I figured

Wrapping the SentryInterceptor#intercept method code with return Sentry.withIsolationScope(async () => {}) makes it work.

Actual fix that I don't understand

If you check my last commit (letscooee/nestjs-sentry-test@2a99b2f), I moved the Sentry.init code from main.ts initialisation to the constructor initialisation of SentryService. Because of this change, the scope started to leak in the requests. The point I didn't understand is that fundamentally, Sentry is being initialised at a later point of time that's the only difference, so why does the request isolation start breaking? That's where I need your expertise.

[Lms24]

Hey @sagrawal31 thanks a lot for the great reproduction! I was able to reproduce it instantly.

You already correctly identified that you get scope leakage because of Sentry initializing too late in the game. Unfortunately, this is expected behaviour or rather, an unfortunate consequence of how OpenTelemetry instruments NodeJS applications.

Fundamentally the thing that's failing is that our SDK (or the Otel SDK under the hood) needs to instrument node:http(s). We do this to capture request spans but even more importantly to isolate requests, more specifically to set an isolation scope as you did in your workaround.

To instrument libraries like http the SDK basically intercepts require('http') calls. To do that, it needs to be initialized before the first such require call. If you move the Sentry.init code to your service, this is too late as the NestJS server is already setting up (afaik by default an Express server which internally uses http).

That's the reason why our docs clearly state that the SDK must be initialized first thing in your main.ts file. I hope this makes sense.

Note, if you're transpiling to ESM (i.e. your built code has import statements instead of require calls) make sure to follow these instructions instead.

[Lms24]

Leaving some more information as to how you can diagnose this: If you set debug: true when initializing the SDK, you get the following output when starting the app and making the two requests:

Early Sentry.init call

Things to note:

• we get debug logs that http and https were patched (red)
• we get the correct, isolated output in beforeSend (yellow)
• also we get information that a new incoming request was received (opentelemetry lines below the yellow boxes)

Late Sentry.init call

In contrast,

• notice the absence of the http(s) patching logs
• we get a warning about the default isolationScope (red) still being set. This confirms that the isolation scope wasn't applied on a per-request basis
• no opentelemetry logs around the incoming requests

[Lms24]

So to conclude, this isn't a bug but unfortunate behaviour. I recommend following our docs for setup and avoiding a late-init of Sentry. If you cannot at all avoid this, there's a compromise to preload the instrumentation part of the SDK and only init the SDK itself later. Follow this guide for it.

Let me know if you have any other questions.