NextJS SSG Error Handling Not Working, Client-side does

[AbhiPrasad]

Discussed in #6254

^{Originally posted by chris-erickson November 21, 2022}
I'm struggling a lot to understand why the server-side error handling isn't working. We have had client side working for quite some time, I'm not sure if server side has ever worked for us (so, I can't point specifically to something we maybe changed as a clue).

Versions:

"next": "13.0.4",
"@sentry/nextjs": "7.20.0",

I made a testing page that will throw either in getServerSideProps directly, or in an async function called there (to simulate a third-party API call that dies for some reason). When I load the page in Vercel, the logs emit:

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: Http
Sentry Logger [log]: Integration installed: OnUncaughtException
Sentry Logger [log]: Integration installed: OnUnhandledRejection
Sentry Logger [log]: Integration installed: ContextLines
Sentry Logger [log]: Integration installed: Context
Sentry Logger [log]: Integration installed: Modules
Sentry Logger [log]: Integration installed: RequestData
Sentry Logger [log]: Integration installed: LinkedErrors
Sentry Logger [log]: Integration installed: RewriteFrames
Sentry Logger [log]: SDK successfully initialized
Sentry Logger [log]: [Tracing] starting http.server transaction - /errorTester
Sentry Logger [log]: [Tracing] Starting 'function.nextjs' span on transaction '/errorTester' (8e631fbcf4828329).
Sentry Logger [log]: [Tracing] Finishing 'function.nextjs' span on transaction '/errorTester' (8e631fbcf4828329).
2022-11-21T17:02:12.769Z	041218a1-9b0d-4a17-ae99-7c9a27170c39	ERROR	Error: This happened inside the API
 at tester (/var/task/packages/site/.next/server/pages/errorTester.js:51:11)
 at getServerSideProps (/var/task/packages/site/.next/server/pages/errorTester.js:71:15)
 at /var/task/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:34:33
 at /var/task/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:113:20
 at bound (node:domain:421:15)
 at runBound (node:domain:432:12)
 at Object.callTracedServerSideDataFetcher (/var/task/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:128:5)
 at /var/task/node_modules/@sentry/nextjs/cjs/config/wrappers/withSentryGetServerSideProps.js:32:50
 at Object.renderToHTML (/var/task/node_modules/next/dist/server/render.js:506:26)
 at processTicksAndRejections (node:internal/process/task_queues:96:5) {
 page: '/errorTester'
}
RequestId: 041218a1-9b0d-4a17-ae99-7c9a27170c39 Error: Runtime exited with error: exit status 1
Runtime.ExitError

when I run it locally with build/serve I get:

ready - started server on 0.0.0.0:3000, url: http://localhost:3000
info - Loaded env from /Users/me/Development/ginrickey/packages/site/.env.local
info - Loaded env from /Users/me/Development/ginrickey/packages/site/.env.production
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: Http
Sentry Logger [log]: Integration installed: OnUncaughtException
Sentry Logger [log]: Integration installed: OnUnhandledRejection
Sentry Logger [log]: Integration installed: ContextLines
Sentry Logger [log]: Integration installed: Context
Sentry Logger [log]: Integration installed: Modules
Sentry Logger [log]: Integration installed: RequestData
Sentry Logger [log]: Integration installed: LinkedErrors
Sentry Logger [log]: Integration installed: RewriteFrames
Sentry Logger [log]: SDK successfully initialized
Sentry Logger [log]: [Tracing] starting http.server transaction - /errorTester
Sentry Logger [log]: [Tracing] starting http.server transaction - /errorTester
Sentry Logger [log]: [Tracing] Starting 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: [Tracing] Finishing 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: Not capturing exception because it's already been captured.
Error: This happened inside the API
 at tester (/Users/me/Development/ginrickey/packages/site/.next/server/pages/errorTester.js:51:11)
 at getServerSideProps (/Users/me/Development/ginrickey/packages/site/.next/server/pages/errorTester.js:71:15)
 at /Users/me/Development/ginrickey/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:34:33
 at /Users/me/Development/ginrickey/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:113:20
 at bound (node:domain:421:15)
 at runBound (node:domain:432:12)
 at Object.callTracedServerSideDataFetcher (/Users/me/Development/ginrickey/node_modules/@sentry/nextjs/cjs/config/wrappers/wrapperUtils.js:128:5)
 at /Users/me/Development/ginrickey/node_modules/@sentry/nextjs/cjs/config/wrappers/withSentryGetServerSideProps.js:32:50
 at Object.renderToHTML (/Users/me/Development/ginrickey/node_modules/next/dist/server/render.js:506:26)
 at runMicrotasks (<anonymous>)
Sentry Logger [log]: [Tracing] Starting 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: Not capturing exception because it's already been captured.
Sentry: should send
Sentry: should send
Sentry Logger [log]: [Tracing] Finishing 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: [Tracing] Starting 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: [Tracing] Finishing 'function.nextjs' span on transaction '/errorTester' (848e345adae7a90f).
Sentry Logger [log]: [Tracing] Finishing http.server transaction: /errorTester.
Sentry Logger [log]: Flushing events...
Sentry Logger [log]: Done flushing events
Sentry Logger [log]: [Tracing] Finishing http.server transaction: /500.

note that

Sentry: should send
Sentry: should send

comes from the sentry.server.config.js and it's only present in the local use case. This leads me to believe something is disabling sentry when it's deployed but I don't for the life of me know what could be doing that or how to examine it.

import * as Sentry from '@sentry/nextjs';

const SENTRY_DSN = process.env.SENTRY_DSN || process.env.NEXT_PUBLIC_SENTRY_DSN;

Sentry.init({
 dsn: SENTRY_DSN,
 environment: process.env.ACTIVE_ENV,
 tracesSampleRate: 1.0,
 debug: true,
 beforeSend: (e) => {
 console.log('Sentry: should send');
 return e;
 },
});

Relevant parts of the next config looks like

const { formatInTimeZone } = require('date-fns-tz');
const { withSentryConfig } = require('@sentry/nextjs');

const ENVIRONMENTS = {
 DEV: 'dev',
 STAGE: 'staging',
 PROD: 'production',
};
const nextjsEnvironment = process.env.ACTIVE_ENV;
let ENVIRONMENT;
if (nextjsEnvironment === ENVIRONMENTS.STAGE) {
 ENVIRONMENT = ENVIRONMENTS.STAGE;
} else if (nextjsEnvironment === ENVIRONMENTS.PROD) {
 ENVIRONMENT = ENVIRONMENTS.PROD;
} else {
 ENVIRONMENT = ENVIRONMENTS.DEV;
}

const isDev =
 nextjsEnvironment !== ENVIRONMENTS.STAGE &&
 nextjsEnvironment !== ENVIRONMENTS.PROD;
const isProd = nextjsEnvironment === ENVIRONMENTS.PROD;

const SITE_URL =
 process.env.SITE_URL ||
 process.env.URL ||
 process.env.DEPLOY_URL ||
 'https://oursite';

const BRANCH =
 process.env.VERCEL_GIT_COMMIT_REF || process.env.BRANCH || 'unset';
const possibleCommitRef =
 process.env.VERCEL_GIT_COMMIT_SHA || process.env.COMMIT_REF || '000000';
const COMMIT_REF = possibleCommitRef.slice(0, 6);

const now = new Date();
const BUILD_DATETIME_HUMAN = formatInTimeZone(
 now,
 'America/Chicago',
 `EEE. MMMM d, yyyy, K:mm aa 'Central'`
);

const SentryWebpackPluginOptions = {
 silent: false,
 debug: true,
};

/**
 * @type {import('next').NextConfig}
 */
const nextConfig = {
 swcMinify: true,
 reactStrictMode: true,
 trailingSlash: false,
 productionBrowserSourceMaps: true,
 images: {
 domains: ['cdn.sanity.io'],
 // disableStaticImages: true,
 },
 // These vars are injected at build time, and are accessible as `process.env.KEY` in site code
 env: {
 BRANCH: BRANCH,
 COMMIT_REF: COMMIT_REF,
 BUILD_DATETIME_HUMAN: BUILD_DATETIME_HUMAN,
 ACTIVE_ENV: ENVIRONMENT,
 SITE_URL: SITE_URL,
 SANITY_PROJECT_ID: process.env.SANITY_PROJECT_ID,
 SANITY_DATASET: process.env.SANITY_DATASET,
 SANITY_READ_TOKEN: process.env.SANITY_READ_TOKEN || '',
 THEMIS_URL: process.env.THEMIS_URL || 'https://example.com/graphql',
 GIT_REF: process.env.COMMIT_REF,
 SENTRY_DSN: process.env.SENTRY_DSN,
 FATHOM_SITE_ID: process.env.FATHOM_SITE_ID,
 MAPBOX_TOKEN: process.env.MAPBOX_TOKEN,
 ENVIRONMENTS: ENVIRONMENTS,
 IS_PROD: isProd,
 },
 eslint: {
 // We check in CI, so this is duplicate effort: https://nextjs.org/docs/api-reference/next.config.js/ignoring-eslint
 ignoreDuringBuilds: true,
 },
 webpack: (config, options) => {
 config.module.rules.push({
 test: /\.svg$/,
 use: [
 options.defaultLoaders.babel,
 {
 loader: '@svgr/webpack',
 options: { babel: false },
 },
 ],
 });
 return config;
 },
};

module.exports = withSentryConfig(nextConfig, SentryWebpackPluginOptions);

```</div>

[lforst]

Hi, thanks for writing in. We know server-side error capturing on Vercel is super funky at the moment - we compiled a list of what's working on Vercel and what isn't here: #6120

This issue is probably also a duplicate of #6117.

I spent some time troubleshooting why errors thrown in data fetchers on Vercel are weirdly not catchable but I didn't come to a result. We have code that is supposed to catch errors, but the catch block is simply never hit on Vercel:

sentry-javascript/packages/nextjs/src/config/wrappers/wrapperUtils.ts

Lines 36 to 48 in 955a1b2

	export function withErrorInstrumentation<F extends (...args: any[]) => any>(
	origFunction: F,
	): (...params: Parameters<F>) => Promise<ReturnType<F>> {
	return async function (this: unknown, ...origFunctionArguments: Parameters<F>): Promise<ReturnType<F>> {
	try {
	return await origFunction.call(this, ...origFunctionArguments);
	} catch (e) {
	// TODO: Extract error logic from `withSentry` in here or create a new wrapper with said logic or something like that.
	captureException(e);
	throw e;
	}
	};
	}

If I find the time I will reach out to the Vercel folks and ask if they're doing some magic that might mess with the SDK.

[AbhiPrasad]

@chris-erickson if you could also reach out to Vercel, perhaps that can help us dig deeper into this situation. Any help is appreciated. Thanks!

[chris-erickson]

I pinged them on a long running discussion, we'll see. Also skimming the table of known issues, I see that the experimental edge routes is exactly the issues I'm having using the new opengraph image render. Seems like Vercel is outrunning how fast third parties can keep up (not just Sentry, I have a couple things that have recently started throwing warnings in the more recent versions).

[lforst]

Hi @chris-erickson this should be fixed with #6578 in the latest version of the SDK. Feel free to try it out and let us know if it resolved the issue for you!

[github-actions]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀