@sentry/nextjs not reporting errors in next.js api routes on vercel

[bradgarropy]

• Review the documentation: https://docs.sentry.io/
• Search for existing issues: https://github.com/getsentry/sentry-javascript/issues
• Use the latest release: https://github.com/getsentry/sentry-javascript/releases
• Provide a link to the affected event from your Sentry account

Package + Version

• @sentry/browser
• @sentry/node
• raven-js
• raven-node (raven for node)
• other: @sentry/nextjs

Version:

6.17.3

Description

Errors from my frontend using the Throw Error button and errors from my api routes (/subscribe, /twitch) are not working. When pressing the Throw Error button referenced in your documentation, I do not see any network requests going to Sentry. In the api routes, I am seeing my fake error shown in the logs, but again nothing is sent to Sentry.

I have the following environment variables defined in Vercel.

SENTRY_DSN
SENTRY_PROJECT
SENTRY_ORG
SENTRY_URL
SENTRY_AUTH_TOKEN

You can view the source code in the repository, and check out the live demo on the website.

[AbhiPrasad]

Hey thanks for opening an issue!

We did a little investigating here and it seems like it all works fine locally. We then took a look at your client-side code on your deployed site and enabled debug mode. (Every Sentry SDK has a debug mode which enables the debug logger) - and it seems that the SDK is never initialized because there is no valid DSN provided. The SDK is no-op when there is no dsn, and this is probably happening to your API routes as well!

To make sure this isn't something on our end (since we dynamically inject the sentry configs through webpack), could you check that you set the SENTRY_DSN env variable correctly? It might also be that these variables are not set in branch deploys.

If that doesn't go anywhere, it would be great if you could turn on debug mode and do a deploy to Vercel. This will allow us to debug further!

Sentry.init({
  debug: true,
  // pass whatever other options you have
});

[bradgarropy]

Thanks for following up @AbhiPrasad.

I went ahead and committed some changes to enable debug mode. When I run the project locally with vercel dev, I am able to see two instances of the SDK initialize successfully.

<SENTRY_DSN>
Sentry Logger [Log]: Initializing SDK...
Sentry Logger [Log]: Integration installed: InboundFilters
Sentry Logger [Log]: Integration installed: FunctionToString
Sentry Logger [Log]: Integration installed: Console
Sentry Logger [Log]: Integration installed: OnUncaughtException
Sentry Logger [Log]: Integration installed: OnUnhandledRejection
Sentry Logger [Log]: Integration installed: LinkedErrors
Sentry Logger [Log]: Integration installed: RewriteFrames
Sentry Logger [Log]: Integration installed: Http
Sentry Logger [Log]: SDK successfully initialized
<SENTRY_DSN>
Sentry Logger [Log]: Initializing SDK...
Sentry Logger [Log]: Integration installed: InboundFilters
Sentry Logger [Log]: Integration installed: FunctionToString
Sentry Logger [Log]: Integration installed: Console
Sentry Logger [Log]: Integration installed: OnUncaughtException
Sentry Logger [Log]: Integration installed: OnUnhandledRejection
Sentry Logger [Log]: Integration installed: LinkedErrors
Sentry Logger [Log]: Integration installed: RewriteFrames
Sentry Logger [Log]: Integration installed: Http
Sentry Logger [Log]: SDK successfully initialized

[bradgarropy]

A lightbulb went on and I thought it might be because I'm not prefixing my environment variable with NEXT_PUBLIC_. So I gave that a try and frontend errors are now being reported.

However I'm still not seeing anything coming from my API routes.

[lobsterkatie]

Hi, @bradgarropy.

Glad to hear front end errors are working now! I'm curious, because this recently came up elsewhere, where are you setting that DSN env variable? And are you setting it with the NEXT_PUBLIC_ prefix or not?

As to your API routes, can you confirm that nextjs picks them up, and will direct requests to them? (I cloned and tried to build yours to test it, but couldn't get past a number of build errors.)

When I move my api folder out of pages and to the root level of my project, nextjs ignores it entirely. The placement of this folder is why Sentry is not working - we only inject into files in pages, as that's where the nextjs docs say API routes should be.

[bradgarropy]

Hey @lobsterkatie,
You weren't able to build my site locally because it depends on API keys (provided through environment variables) for data fetching that you didn't have, sorry!

I'm hosted on Vercel, so I defined my environment variable there, as NEXT_PUBLIC_SENTRY_DSN. Based on my experience it seems like the NEXT_PUBLIC_ prefix is required, as the variable is being used in client side code. I added some logs to the api routes and can confirm the variable is being picked up.

But, I think I just found the actual root cause. Vercel supports serverless functions out of a top level api directory, which has been working fine for my Next.js site when running vercel dev. However, Vercel seems to treat Next.js applications a little differently, asking you to put api routes in the page/api directory.

After moving my api routes into the Next.js application, Sentry is working just fine! Thanks for your support and I'll close the issue.

[rfdearborn]

Hey folks - within our Next.js Vercel project, we've recently moved API routes from pages/api/to top level api/ in order to build out a couple of non-Node.js-runtime endpoints. Doing so has broken Sentry's API route monitoring as described above. Other than moving our routes back to pages/, is there any straightforward restoration you can recommend?

[lforst]

@rfdearborn Hi, admittedly that is a use case we haven't fully explored yet.

The @sentry/nextjs SDK does a few things under the hood that you would need to do manually here.

First, you probably need to call Sentry.init() in the scope of your API route (not in the handler) so the SDK gets initialized. In the /pages folder this happens automatically.

Next, you will probably need to wrap your route handler in withSentryAPI. This is so that errors are properly recorded.

I haven't actually done this yet but this is what I would try first. If you want and have the time you could open a separate issue so we can properly track this feature request and gauge interest.

[Jay-flow]

Any update? I'm have the same problem. "next": "13.0.6" has a path at /pages/api.

[lforst]

@Jay-flow we need more information. Can you open another issue with steps to reproduce your problem?

[Jay-flow]

@Jay-flow we need more information. Can you open another issue with steps to reproduce your problem?

I wrote a new issue! #6450