@sentry/nextjs not reporting issues i serverless functions

[ThePaulMcBride]

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

Version:

6.5.1

Description

I've recently started using the @sentry/nextjs package for a Nextjs site. I've followed through with the installation guide with one exception. I'm using environment variables instead of the file generated by the wizard. On the client side it works great, the releases and bugs are being tracked, but I'm getting no reports from my serveless functions when they throw errors.

import { withSentry } from "@sentry/nextjs";

const handler = async (req, res) => {
  throw new Error("API throw error test");
  res.status(200).json({ name: "John Doe" });
};

export default withSentry(handler);

This is the serverless function I am testing and nothing is showing up in my Sentry dashboard when it fails.

[AbhiPrasad]

Hey, thank you for reporting. Could you share your next config with us? Also, is this happening during local development, or when deployed on something like Vercel?

[ThePaulMcBride]

Sure, The contents on my next.config.js is below...

const { withSentryConfig } = require("@sentry/nextjs");
const withImages = require("next-images");
const withBundleAnalyzer = require("@next/bundle-analyzer")({
  enabled: process.env.ANALYZE === "true",
});
const webpack = require("webpack");
const withPlugins = require("next-compose-plugins");
const withTM = require("next-transpile-modules")(["@medv/finder"]);

const basePath = "";

const nextConfig = {
  basePath,
  productionBrowserSourceMaps: true,
  images: {
    domains: ["x", "y", "z"],
  },
  webpack(config, options) {
    config.module.rules.push({
      test: /\.ejs$/,
      use: {
        loader: "ejs-compiled-loader",
        options: {
          htmlmin: true,
          htmlminOptions: {
            removeComments: true,
          },
        },
      },
    });

    config.module.rules.push({
      test: /\.worker\.js$/,
      use: { loader: "worker-loader" },
    });

    config.plugins.push(
      new webpack.ProvidePlugin({
        _: "underscore",
      })
    );

    config.plugins.push(
      new options.webpack.DefinePlugin({
        "process.env.NEXT_IS_SERVER": JSON.stringify(
          options.isServer.toString()
        ),
      })
    );

    return config;
  },

  async redirects() {
    return [
      {
        source: "/",
        destination: `${process.env.API_URL}/`,
        permanent: true,
      },
      {
        source: "/blog",
        destination: `${process.env.API_URL}/blog`,
        permanent: true,
      },
      {
        source: "/blog/:slug*",
        destination: `${process.env.API_URL}/blog/:slug*`,
        permanent: true,
      },
      {
        source: "/changelog",
        destination: "/changelog/page/1",
        permanent: true,
      },
    ];
  }
};

const SentryWebpackPluginOptions = {};

// Make sure adding Sentry options is the last code to run before exporting, to
// ensure that your source maps include changes from all other Webpack plugins
module.exports = withPlugins(
  [
    withBundleAnalyzer,
    withImages,
    withTM,
    [withSentryConfig, SentryWebpackPluginOptions],
  ],
  nextConfig
);

This happens when deployed to vercel, though it doesn't report errors locally either (is it supposed to?).

[a-ayala]

same issue here, any luck?

[ThePaulMcBride]

No, I've not managed to get it working yet

[nickfreeman]

6.5.0 originally broke all serverless functions. 6.5.1 definitely broke reporting. Any serverless function wrapped with withSentry that throws an error will not trigger a Sentry error in production. Reverting back to 6.4.1 has fixed this

[DavidChouinard]

For context: we had this issue when we first manually integrated Sentry with Vercel (before the Next.js plugin). The issue, as I remember, is that Sentry queues up exceptions to be sent to the server but Vercel terminates the function instantaneously — causing the exception to be lost.

Adding await Sentry.flush(2000) to the error path fixed the issue, the Next.js library should probably do that by default.

[nickfreeman]

@DavidChouinard interesting, having no issues with error logging for serverless Vercel functions in 6.4.1 but also tried 6.7.2 yesterday which was unable to log exceptions for serverless functions

[Vadorequest]

For me, all serverless endpoints are broken when wrapping them with withSentry. See #3750

Reverting to 6.4.1 didn't change anything.

[ThePaulMcBride]

Yeah I have this running on a few projects hosted on Vercel and the server side error are never reported

[Vadorequest]

@ThePaulMcBride Maybe this comment might give you some direction. #3691 (comment)

I only fixed this issue myself yesterday, it's under-documented, unfortunately.

[ThePaulMcBride]

I would have thought that this would be handled in the withSentry wrapped function. I assume it is already catching any errors that bubble up so should have the opportunity to flush them to sentry before rethrowing/handling the error.

That way the serverless function wouldn't be terminated before the error is reported. I wonder if it would be possible to make it work like that?

[DavidChouinard]

About a month ago a change was made to the withSentry function to add a blind try/catch around the flush call. The change was labeled:

It seems that awaiting a flush() call is throwing errors in
Webpack 5. This crashes the server as the handler has already
sent a response at that point. This patch wraps the flush call
in a try, catch until we can figure out a better fix.

It seems like the flush call is probably failing silently and causing the symptoms we're seeing here. Don't know what the solution is but seems like a good place to start digging. (cc. @AbhiPrasad)

[DavidChouinard]

Possibly related issue

[AbhiPrasad]

Hey everyone, thanks for all the comments and feedback.

We are currently working on a patch to fix these issues (and some of the linked issues) by changing how we do server side initialisation of the Sentry SDK - we hope to push something out ASAP.

[Gomah]

Is it still recommended to use { target: 'experimental-serverless-trace' } as stated on the Sentry + Next.js manual setup docs?

[tomrule007]

Not sure what kind of help this is but a current temporary solution I am using is to manually check for client and call Sentry.Init manually if not present.

// Added to the top of my route handlers
if (!Sentry.getCurrentHub().getClient()) {
  console.log('Manual Sentry.Init')
  Sentry.init({ dsn: process.env.NEXT_PUBLIC_SENTRY_DSN })
}

Not exactly understanding what init does, I dont know the the real performance hit I am taking with this manual hack but it appears to be adding around ~100ms delay

@Gomah the experimental flag seemed to have not effect for me.

[DavidChouinard]

@AbhiPrasad any update?

[AbhiPrasad]

Hey. The release in 6.9.0 reworked our server side init as per #3786. This means you should start getting transactions/errors in Vercel serverless functions. We are still investigating some issues with flushing events, you can see the PR description for details, but things should work now.

[alexbchr]

@AbhiPrasad How bad are these flushing issues? Do you have a timeline as to when these issues will be resolved?

I think getting some issues reported is better than none, but flushing issues still seems like a huge concern to me.

[AbhiPrasad]

We have a fix on the way for the flushing issues, but no timeline at the moment. Will update this issue as soon as that is merged and released.

[shauns]

@AbhiPrasad will this flushing change help with issues raised during e.g. getServerSideProps as opposed to plain API routes?

[einSelbst]

Is it still recommended to use { target: 'experimental-serverless-trace' } as stated on the Sentry + Next.js manual setup docs?

@Gomah It might depend on the hosting service you use and maybe also on the nextjs features (you use). I have to use this flag on netlify for my project to work.

[lobsterkatie]

Hi, all.

The flush issue should be fixed in #3811. Once we release that fix (hopefully in the next day or two, as v6.10.0), please give it a try and let us know if you're still having issues.

[georgiosd]

Reverted to 6.4.1 which seems to fix the issue while we wait on 6.10.0

[DavidChouinard]

Has anybody been able to confirm 6.10.0/6.11.0 fixes the error? On 6.11.0 and it works correctly locally but doesn't log any exceptions when deployed to Vercel

[jmurty]

Hi @DavidChouinard @lobsterkatie 6.11.0 wasn't working for me, I just had to downgrade to 6.4.1 to get reporting from Vercel API endpoints.

Since this issue is closed I created a new issue #3917 with my specific experience, but please feel free to close that as a duplicate if it's better to re-open this issue.

[DavidChouinard]

@lobsterkatie @AbhiPrasad any idea why the sdk still fails to capture exceptions in Vercel with 6.11.0? Happy to setup a minimal demonstration

[AbhiPrasad]

Hey we are investigating, thanks for letting us know about your issues.