Sentry.init no longer being called after sdk upgrade

[Blitz2145]

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

SDK Version

7.58.0

Framework Version

Nextjs 13.0.6

Link to Sentry event

No response

SDK Setup

import * as Sentry from '@sentry/nextjs';
import prisma from 'lib/server/prisma';

const SENTRY_DSN = process.env.SENTRY_DSN;

Sentry.init({
  dsn:
    SENTRY_DSN,
  enabled: process.env.NODE_ENV === 'production',
  environment: process.env.NEXT_PUBLIC_ENVIRONMENT_NAME,
  ignoreErrors: [
    // See: https://stackoverflow.com/questions/55738408/javascript-typeerror-cancelled-error-when-calling-fetch-on-ios
    'TypeError: cancelled',
    'AbortError: The user aborted a request.',
    'AbortError: Fetch is aborted',
    'Relay: Missing @required value',
    // Special cased in the UI to show a refresh button.
    'GraphQL operations must contain a non-empty `query` or a `persistedQuery` extension.',
    'This Suspense boundary received an update before it finished hydrating.',
    // These errors are thrown when the user needs to re-authenticate their MS account.
    'The provided grant has expired due to it being revoked, a fresh auth token is needed. The user might have changed or reset their password.',
    /^User's email .+ does not match Microsoft username .+$/,
  ],
  denyUrls: [
    // See: https://stackoverflow.com/questions/67224859/typeerror-illegal-invocation
    'googletagmanager.com',
  ],
  tracesSampler: (samplingContext) => {
    if (samplingContext.transactionContext.name.includes('ingr3ss')) {
      return 0;
    }

    return process.env.NEXT_PUBLIC_ENVIRONMENT_NAME === 'staging' ? 1 : 0.25;
  },
  integrations: [new Sentry.Integrations.Prisma({ client: prisma })],
});

Steps to Reproduce

1. From sentry/nextjs v7.56.0 upgrade to v7.57.0 or later
2. Sentry.init is no longer being called automatically on startup

Expected Result

1. From sentry/nextjs v7.56.0 upgrade to v7.57.0 or later
2. Sentry works normally after upgrade

Actual Result

After upgrading the sdk following logs appear when errors are captured and we don't see the file with the sentry.init call being loaded at all. We noticed all server-side errors were no longer captured after the sdk upgrade. We think it started occuring after this change, #8368 Happy to help repro this, we reached out to sentry support but they told us to file a GH issue.

Tracing extension 'startTransaction' has not been added. Call 'addTracingExtensions' before calling 'init':
Sentry.addTracingExtensions();
Sentry.init({...});

Tracing extension 'startTransaction' has not been added. Call 'addTracingExtensions' before calling 'init':
Sentry.addTracingExtensions();
Sentry.init({...});

[AbhiPrasad]

Hey @Blitz2145, thanks for writing in! Are you running the app on Vercel?

[Blitz2145]

Hey @AbhiPrasad we are not running on vercel. We are using Google cloud run, so a server environment not any edge runtime. We are using a custom server in next js, but that wasn't an issue before.

[AbhiPrasad]

We're taking a look trying to reproduce, sorry for the trouble in the mean time!

[Lms24]

@Blitz2145 can you show us your next.config.js? I'm curious how you configured your withSentryConfig options.

Also, the Sentry.init code you posted above is from your sentry.server.config.ts, right?

[Blitz2145]

@Blitz2145 can you show us your next.config.js? I'm curious how you configured your withSentryConfig options.

Also, the Sentry.init code you posted above is from your sentry.server.config.ts, right?

@Lms24 Thanks, if you can access support ticket #98294 I also attached more config files there. Yes, the init code was added to sentry.server.config.ts.

...
/** @type {Partial<import('@sentry/webpack-plugin').SentryCliPluginOptions>} */
const sentryWebpackPluginOptions = {
  org: 'revere-cre',
  project: 'revere-cre',
  silent: process.env.NODE_ENV !== 'production',
  // Only upload sourcemaps when a release name is specified.
  dryRun: process.env.NEXT_PUBLIC_RELEASE == null,
  authToken: process.env.SENTRY_AUTH_TOKEN,
};

/** @type {Partial<import('next').NextConfig>} */
const nextConfig = {
  swcMinify: false,
  reactStrictMode: true,
  sentry: {
    hideSourceMaps: true,
    widenClientFileUpload: true,
    disableServerWebpackPlugin: process.env.NEXT_PUBLIC_RELEASE == null,
    disableClientWebpackPlugin: process.env.NEXT_PUBLIC_RELEASE == null,
    autoInstrumentServerFunctions: false,
  },
...

[kerenkhatiwada]

ZD ticket

[AbhiPrasad]

@lforst any idea what this could be?

[lforst]

@lforst any idea what this could be?

No idea. I would try upgrading to the newest SDK version and if the issue persists provide a small reproduction example.

[Blitz2145]

The issue still persists as of v7.61.1 Will need to come up with a smaller repro, but might take a while.

[lforst]

I looked at this again. Something about your SDK setup looks extremely fishy.

Are you installing the Prisma integration in the frontend init (sentry.client.config.ts)? Cause that will not work for obvious reasons: browsers generally don't run prisma.

[Blitz2145]

I looked at this again. Something about your SDK setup looks extremely fishy.

Are you installing the Prisma integration in the frontend init (sentry.client.config.ts)? Cause that will not work for obvious reasons: browsers generally don't run prisma.

Thanks for following up. I am not running the prisma integration in the frontend, the prisma integration is in sentry.server.config.ts.

We've also upgrade nextjs to v13.4.12 but that didn't change anything. Our setup is peculiar because we are not using auto instrumentation of api handlers on the server-side (it was too buggy and broke our app) and a custom server.

[lforst]

it was too buggy and broke our app

Do you mind sharing in what way it was buggy? Thanks!

I think I know what the issue is now. On the server side we're only importing sentry.server.config.ts when autoInstrumentServerFunctions isn't set to false. This is obviously not what we want.

[Blitz2145]

it was too buggy and broke our app

Do you mind sharing in what way it was buggy? Thanks!

I think I know what the issue is now. On the server side we're only importing sentry.server.config.ts when autoInstrumentServerFunctions isn't set to false. This is obviously not what we want.

Thanks for the fix, I'll try out the new release and see if it fixes our issues. We ran into trouble with the autoinstrumentation of API handlers causing connection close issues on handlers that used streaming responses. We also noticed a noticeable performance hit when using instrumentation in load tests, so we switched to opt-in explicit instrumentation. In general, its seems pretty hard to auto instrument reliably in the JS ecosystem.

[lforst]

Thanks for providing insight into what didn't work for you. As a follow-up, are you deploying your app to Vercel or AWS Lambdas, or some other hosting provider that runs AWS Lambdas under the hood?

In general, its seems pretty hard to auto instrument reliably in the JS ecosystem.

Word.

[Blitz2145]

Thanks for providing insight into what didn't work for you. As a follow-up, are you deploying your app to Vercel or AWS Lambdas, or some other hosting provider that runs AWS Lambdas under the hood?

In general, its seems pretty hard to auto instrument reliably in the JS ecosystem.

Word.

We are deploying to google cloud run (aka long running containers), nothing lambda like yet.

[lforst]

Thanks for providing insight into what didn't work for you. As a follow-up, are you deploying your app to Vercel or AWS Lambdas, or some other hosting provider that runs AWS Lambdas under the hood?

In general, its seems pretty hard to auto instrument reliably in the JS ecosystem.

Word.

We are deploying to google cloud run (aka long running containers), nothing lambda like yet.

Interesting. We should investigate then what seems to be causing the overhead.