sentry-javascript: Asynchronous errors aren't being reported in Next.js data-fetching methods on Vercel
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? If you use the CDN bundles, please specify the exact bundle (e.g. bundle.tracing.min.js) in your SDK setup.
SDK Version
7.44.2
Framework Version
12.2.3
Link to Sentry event
SDK Setup
Our source is public here. Debugging branch here, on the latest Sentry version.
Sentry.init({
debug: true,
dsn: SENTRY_DSN,
sampleRate: 1.0,
normalizeDepth: 5,
initialScope: {
tags: {
'next.runtime': 'server',
},
},
beforeSend(event, hint) {
const ex = hint.originalException;
if (ex instanceof Error) {
// Happens when receiving a bad url that fails to decode
if (ex.message.match(/URI malformed/)) {
return null;
}
}
return event;
},
});
Steps to Reproduce
Similar to https://github.com/getsentry/sentry-javascript/issues/6117 (which fixed this problem for synchronous errors), but reject a promise or throw an error in an async callback. When the project is run locally, the error is reported to Sentry. When deployed to Vercel, the error never appears in Sentry.
import { GetServerSideProps } from 'next';
const MyComponent = () => {
return <h1>Hello World!</h1>;
};
export const getServerSideProps: GetServerSideProps = async (context) => {
if (context.query.myParam === 'two') {
// only throw conditionally so that this page actually builds
Promise.reject(new Error("We don't like page two!"));
}
return { props: {} };
};
export default MyComponent;
Expected Result
An error like this one gets reported to Sentry.
Actual Result
No error is reported to Sentry. Here are the Vercel logs, if it’s helpful:
Unhandled Promise Rejection {"errorType":"Runtime.UnhandledPromiseRejection","errorMessage":"Error: We don't like page two","reason":{"errorType":"Error","errorMessage":"We don't like page two","stack":["Error: We don't like page two"," at getServerSideProps (/var/task/frontend/.next/server/pages/myPage.js:27:24)"," at Object.renderToHTML (/var/task/node_modules/.pnpm/next@12.2.3_t7ss3ubh4wigfvyfclbvqff3gm/node_modules/next/dist/server/render.js:573:26)"," at processTicksAndRejections (node:internal/process/task_queues:96:5)"," at async doRender (/var/task/node_modules/.pnpm/next@12.2.3_t7ss3ubh4wigfvyfclbvqff3gm/node_modules/next/dist/server/base-server.js:915:38)"," at async cacheEntry.responseCache.get.isManualRevalidate.isManualRevalidate (/var/task/node_modules/.pnpm/next@12.2.3_t7ss3ubh4wigfvyfclbvqff3gm/node_modules/next/dist/server/base-server.js:1020:28)"," at async /var/task/node_modules/.pnpm/next@12.2.3_t7ss3ubh4wigfvyfclbvqff3gm/node_modules/next/dist/server/response-cache.js:69:36"]},"promise":{},"stack":["Runtime.UnhandledPromiseRejection: Error: We don't like page two"," at process.<anonymous> (file:///var/runtime/index.mjs:1188:17)"," at process.emit (node:events:525:35)"," at process.emit (node:domain:489:12)"," at emit (node:internal/process/promises:140:20)"," at processPromiseRejections (node:internal/process/promises:274:27)"," at processTicksAndRejections (node:internal/process/task_queues:97:32)"]}
Unknown application error occurred
Runtime.Unknown
CC @lforst
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 2
- Comments: 17 (8 by maintainers)
@masonmcelvain Yes, bugging the Next.js maintainers about a proper on-error hook would be amazing. Afaik they’re looking into telemetry anyhow so this might even align with their objectives!
The issue here seems to be related to the lifecycle of Next.js 13. I managed to solve the problem by explicitly calling the
Sentry.initmethod before invokingSentry.captureException(error). Here’s an example of how I achieved this:This is still happening, so I don’t think it should be closed.
@masonmcelvain Generally it is already using the new mechanism under the hood. I don’t think this will resolve this issue though.