Errored API routes trigger "API resolved without sending a response" `7.32.1`

[AbhiPrasad]

          I can confirm this is an issue on `7.32.1` but the same pattern was working fine on `7.31.1`.

I didn't see anything in the diff which would indicate the breaking change, but the constant logging has definitely returned. Downgrading to 7.31.1 resolves again.

Originally posted by @bsplosion in #3852 (comment)

[AbhiPrasad]

@lforst could you take a look when you get some time?

[lforst]

@bsplosion We didn't change anything in that logic so I wonder what might cause this.

• What Next.js version are you using?
• Can you share your Next.js config?
• Can you provide a reproduction example that shows this happening? Thanks!

[bsplosion]

• Reproduced on Next.js 13.1.2 and 13.1.5
• Next.js config below, don't think there's anything sensitive in it.
• I haven't tried to make a minimum reproduction, probably won't have time for a while due to project demands. The issue in my case is occurring in a large monorepo (via NX) and I can potentially try to pare it down to a minimum at some point in the future if the cause still isn't clear.

next.config.js:

const { withSentryConfig } = require('@sentry/nextjs');

const isLocal = !!process.env.NX_WORKSPACE_ROOT;

const MS_PER_SECOND = 1000;
const SECONDS_PER_DAY = 86400;

const env = {
  // Set env variables required for reference in CLI-level utilities
  // Any variables which need to have the "NEXT_PUBLIC_" prefix on the variable name removed should occur here
  // e.g. Sentry can't parse for NEXT_PUBLIC_SENTRY_URL and expects SENTRY_URL to be available,
  // even though that naming would make it a server-only value since it's missing the "NEXT_PUBLIC_" prefix
  SENTRY_URL: process.env.NEXT_PUBLIC_SENTRY_URL,
  SENTRY_ORG: process.env.NEXT_PUBLIC_SENTRY_ORG,
  SENTRY_PROJECT: process.env.NEXT_PUBLIC_SENTRY_PROJECT,
  SENTRY_AUTH_TOKEN: process.env.NEXT_PUBLIC_SENTRY_AUTH_TOKEN,

  // Override the canonical domain for local dev
  // Note: this may not take effect in an expected manner
  NEXT_PUBLIC_CANONICAL_DOMAIN:
    process.env.PROJECT_ENV === 'local' ? 'http://localhost:3000' : process.env.NEXT_PUBLIC_CANONICAL_DOMAIN,
};

/**
 * @type {import('@nrwl/next/plugins/with-nx').WithNxOptions}
 **/
const nextConfig = {
  // Number of seconds with no static pages generated before error (default is 60 seconds)
  staticPageGenerationTimeout: 600,

  // Pull env into config
  env,

  // Enable production source maps for debugging and Lighthouse insights
  productionBrowserSourceMaps: true,

  onDemandEntries: {
    // Period (in ms) where the server will keep pages in the buffer
    maxInactiveAge: SECONDS_PER_DAY * MS_PER_SECOND,
    // Number of pages that should be kept simultaneously without being disposed
    pagesBufferLength: 1000,
  },

  compress: true,

  compiler: {
    // removeConsole: {
    //   exclude: ['error', 'debug'],
    // },
  },
};

// SENTRY WRAPPER
const sentryWebpackPluginOptions = {
  // Additional config options for the Sentry Webpack plugin. Keep in mind that
  // the following options are set automatically, and overriding them is not
  // recommended:
  //   release, url, org, project, authToken, configFile, stripPrefix,
  //   urlPrefix, include, ignore

  // Suppresses all logs
  silent: true,

  // For all available options, see:
  // https://github.com/getsentry/sentry-webpack-plugin#options.
};
const sentryWrapper = withSentryConfig(nextConfig, sentryWebpackPluginOptions);

// NX WRAPPER
const nxWrapper = isLocal ? require('@nrwl/next/plugins/with-nx') : (a) => a;
let nxWrappedExport;
if (process.env.ANALYZE === 'true') {
  // Only run the require if ANALYZE is requested
  nxWrappedExport = nxWrapper(
    require('@next/bundle-analyzer')({
      enabled: true,
    })(sentryWrapper)
  );
} else {
  nxWrappedExport = nxWrapper(sentryWrapper);
}

module.exports = nxWrappedExport;

[lforst]

Thanks! Is there weird build output?

[bsplosion]

Not that I've seen - just ran another build and it cleared without any issues or messaging that had anything to do with Sentry.

Worth noting, I'm not actually suppressing those logs with the SENTRY_IGNORE_API_RESOLUTION_ERROR config since it wasn't necessary on the versions prior to 7.32.1. Adding that config into the env still didn't resolve it on that version, though. I haven't tested 7.32.0 or others, could be that the issue was reintroduced on the minor version bump.

[lforst]

@bsplosion are you sure this worked on version 7.31.1?

[lforst]

@bsplosion Also can you maybe share the file of the route this is happening on? Thanks!

[bsplosion]

@lforst I just checked again and it's still not having that logging issue under 7.31.1, though maybe something else is broken on that version which causes it to also not log?

Regarding the route it triggers on, it's every API route, down to the most basic. We have some proprietary API request wrappers in place that I don't believe are necessarily impacting this, but here's a basic stripped example in case anything leaps out:

class ApiCurrentUserController extends NextApiAuthController {
  constructor() {
    // No special restraints, will return UNAUTHORIZED from GET if no valid session
    super({});
  }

  getAction = async (req: NextApiRequestWithUser, res: NextApiResponse) => {
    if (req.user) {
      if (req.user.teamID) {
        const team = await getAdminFirestore()
          .collection('teams')
          .doc(req.user.teamID)
          .get()
          .then(async function (doc) {
            if (doc.exists) {
              return {
                id: req.user.teamID,
                ...doc.data(),
              };
            }
            return null;
          });
        return {
          ...req.user,
          platformUser: {
            ...req.user.session.platformUser,
            team: team,
          },
        };
      } else {
        return req.user;
      }
    } else {
      res.status(HttpStatusEnum.UNAUTHORIZED).send('Unauthenticated');
    }
  };
}

const apiController = new ApiCurrentUserController();
export default apiController.processRequest;

There are several imports that I don't have defined on this snippet, like NextApiRequestWithUser which is internal. Let me know if you see anything that could be symptomatic and I can find time to take a look.

[lforst]

@bsplosion Hmm there could be something triggering this on your end depending on what apiController.processRequest looks like. Can you share the code of that function? (feel free to leave out sensitive parts - mostly res.send, res.end and res.json calls are relevant)

[bsplosion]

@lforst It's going to be a rabbit hole - that function has a bunch of other provider services that are hooked, which in turn do some other stuff that could potentially affect it.

Are you saying that you're seeing the extra logging on 7.31.1? Since I can reproduce that issue under 7.32.1 maybe we should just start there then and assume that my code was interacting with Sentry in some odd way under the prior version.

[lforst]

After thinking about this some more, I think this is related to #6919. Can you try upgrading to version 7.33.0?

[tonyxiao]

This isn't just on error api. I have the simplest possible handler in api/test.ts as follow

export default ((req, res) => {
  res.send('Data')
}) satisfies NextApiHandler

And I still get this issue. I'm on @sentry/nextjs 7.34.0

[lforst]

@tonyxiao I cannot reproduce it. Do you happen to be calling that handler from some other place? Are you wrapping your routes manually with withSentry or withSentryAPI? Are you on vercel or is this also happening locally?