@sentry/nuxt breaks Nuxt context for ~1% of requests

[maxtomczyk]

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/nuxt

SDK Version

9.1.0

Framework Version

3.15.4

Link to Sentry event

No response

Reproduction Example/SDK Setup

const release = `${process.env.NUXT_PUBLIC_APP_NAME}@${ver.replace('v', '')}`

Sentry.init({
  dsn: process.env.NUXT_PUBLIC_SENTRY_DSN,
  environment: process.env.NUXT_PUBLIC_ENVIRONMENT,
  release,
  tracesSampleRate: 0.5,
  debug: true,
})

Steps to Reproduce

1. Build Nuxt app
2. Start server with node --import ./dist/apps/core/.output/server/sentry.server.config.mjs ./dist/apps/core/.output/server/index.mjs
3. Run Grafana K6 to test

Expected Result

All requests are correctly handled.

Actual Result

About 1% of requests fails with 500 status code:

K6 results for node ./dist/apps/core/.output/server/index.mjs:

K6 results for node --import ./dist/apps/core/.output/server/sentry.server.config.mjs ./dist/apps/core/.output/server/index.mjs:

I spent the last few days trying to fix or at least find the cause of this issue. I discovered that the 500 status codes are caused by the nuxt instance unavailable error thrown from the pinia store setup function. It's not logged to console because setup function is called inside vue's runWithContext, which doesn't throw error.

Another clue is the fact that the issue doesn't occur with k6 simultaneity set to 1, which makes me believe it may be some race condition introduced by @sentry/node.

Also, commenting maybeInitializeEsmLoader function call in @sentry/node, while it's not a solution, maybe it will make it easier to find root cause.

I'm aware that this issue provides a small number of details, but unfortunately, I'm not able to share the codebase with you, however, I will be happy to provide you more details as needed.

[s1gr1d]

Thanks for taking the time and looking into this!

• Pinia: This is definitely something we can easily handle in the SDK
• Potential Race Condition: As this issue does not occur with simultaneous users (VUs if I am correct?), it could definitely be a race condition. But I don't know where yet. The server-side adds a timeout for flushing events when they are serverless but you should not run into this here, as you need to run this in a serverless environment (code here).
• Commenting maybeInitializeEsmLoader(): I am not sure what you mean here, can you elaborate?

[maxtomczyk]

Thanks for replying that fast.

• Potential Race Condition: You are correct, I meant VUs. Also, we don't use serverless for our applications.
• Commenting maybeInitializeEsmLoader(): I meant modifying built @sentry/node to not call it:

[s1gr1d]

I know you meant commenting it like this :)
I was just wondering what you think would be the change and if you already tried it. Did you already try it?

You could either build the @sentry/node package on your machine with this change or just change this line (like you already did) in the built Sentry folder in the node_modules (you would have to do this in the cjs and esm folder of the build output - just to be sure).

[maxtomczyk]

It looks like I forgot to write about the results of commenting maybeInitializeEsmLoader. The issue doesn't occur with this code commented.