@sentry/nextjs not reporting errors from API (serverless) endpoints in Vercel #3917
Comments
|
Bummer, also experiencing this — should have been fixed with #3643 but appears to still be an issue |
|
Hi, @jmurty and @DavidChouinard. Can you please set Also, can you please post your Thanks! |
lobsterkatie
added
Package: nextjs
|
Sure, And Vercel logs for the function invocation: Note that Sentry works correctly locally but things failed when deployed to Vercel. |
|
Hi @lobsterkatie I have set up a minimal example Next.js + Sentry project to demonstrate the issue: https://github.com/jmurty/nextjs-sentry-vercel-test This project is set up using the Next.js and Sentry installation wizards, with some extra steps to work better with Vercel. Hopefully the commit messages explain what I did. I also set up a new Sentry project to log messages to: https://sentry.io/organizations/murty/issues/?project=5925157 (org When run the app locally with The same app is deployed to Vercel at https://nextjs-sentry-vercel-test.vercel.app/ The /api/test4 API endpoint explicitly catches and captures the error to Sentry. The /api/test3 is closest to this issue: an error raised in the Next.js handler function that should be caught and captured by The other two examples trigger errors outside the scope of the the handler function and Here are the logs from Vercel after hitting the four error-triggering API endpoints: |
|
I also created a This branch is running on Vercel at https://nextjs-sentry-vercel-test-git-sentry-641-jmurty.vercel.app/ and with it the /api/test3 trigger is logged unlike with version 6.11. This matches my experience where downgrading fixed logging of errors within the handler function. The client-side and /api/test4 triggers are also logged, like the 6.11 version. The /api/test1 and /api/test2 example errors are not logged. Here are the Vercel logs again for the 6.4.1 deployment: |
|
@jmurty @DavidChouinard Thanks to both of you! One of my colleagues has been looking at this while I've been pulled away on another project, and I'm now going to poke at it, too. Will let you know what I come up with! |
|
@lobsterkatie have you been able to replicate the issue on your side? |
|
@lobsterkatie I have the same issue, but in my case both on the client and server-side. I use I do not get any error in both client and server logged, unless I enabled capturing console.error statements (with the Note: I also tried v6.4.1, but that did not work either. My sentry config: I have the following nextjs config: |
I have the same issue and I managed to reproduce what @jmurty mentions above. Using: |
|
You're a hero @jmurty, I pulled in sentry for a fresh project and banged my head against the wall way too much before downgrading to |
|
Ah shit, so So because none of export const withSentry = (handler: ApiHandler) => {
return async (req: NextApiRequest, res: NextApiResponse) => {
try {
const handlerResponse = await handler(req, res);
return handlerResponse;
} catch (e) {
Sentry.init({
dsn: SENTRY_DSN,
tracesSampleRate: 0.001,
});
Sentry.captureException(e);
return new Promise<void>((resolve) => {
Sentry.flush(2000).finally(() => {
res.status(500).send('Something went wrong');
resolve();
});
});
}
};
};Would honestly be so cool if you guys fixed this. |
|
@lobsterkatie any update? |
|
I have re-tested my example repo after upgrading to Following @anguskeatinge's suggestion I added a Using the very basic custom |
|
I have taken another look at this in a new branch of my test repo where I copied in the latest official I ended up with this slight adaptation of the official What fixed this (in my testing) was to move the clean-up code that finishes a transaction and flushes to Sentry into a stand-alone function, then call that function from both the I found that the This is a naive fix: I'm not sure why I will submit my version as a PR. |
Potential fix for getsentry#3917 to ensure Sentry error reporting clean-up is done -- transaction finished and error flushed -- when run from a Vercel deployment, by explicitly calling the clean-up code in two places: directly from the `withSentry` handler wrapper function, as well as the existing monkey-patched `res.end()`. In Vercel the `res.end()` function is not (or is not always) called, which means the prior approach that relied on monkey-patching of that function for clean-up did not work in Vercel. Note 1: this is a naive fix: I'm not sure why res.end() isn't called as expected or if there might be a better target for monkey- patching. Note 2: a new `__flushed` variable is used to avoid running the clean-up code twice, should both the explicit and the monkey-patched path be run. See the TODO asking whether this flag should be set at the beginning, instead of the end, of the clean-up function `finishTransactionAndFlush()`
|
Looks like sentry-javascript/packages/nextjs/src/utils/withSentry.ts Lines 76 to 90 in 952850f Probably it should be changed to something like this: catch (e) {
if (currentScope) {
...
captureException(e);
await flush(2000)
throw e;
}
else {
throw e;
}
} This fix probably explains why the workaround mentioned above is working. |
|
Also experiencing this issue with @sentry/nextjs v6.13.3 Have experienced issues like this for a long time on NextJS, which makes Sentry almost impossible to use in production, since the issues come and go and take quite a long time to get fixed 😢 |
|
Same here! We just stopped using withSentry altogether, and use Sentry.captureException instead. Seems to be working fine. |
|
We're still using Sentry version |
|
@lobsterkatie any word from your colleague? |
|
Is it likely that the difficulty collecting errors from Vercel will be fixed, and much more reliable, by using the new Middelware feature of the Next.js 12 release? |
|
Hi, all. Sorry for the delay.
This is right, and is exactly what #4027 is designed to fix. I (and it) got blocked on a few other things recently, but I'm going to give this another look this week. |
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
In our nextjs API route wrapper `withSentry`, we capture any errors thrown by the original handler, and then once we've captured them, we rethrow them, so that our capturing of them doesn't interfere with whatever other error handling might go on. Until recently, that was fine, as nextjs didn't actually propagate the error any farther, and so it didn't interfere with our processing pipeline and didn't prevent `res.end()` (on which we rely for finishing the transaction and flushing events to Sentry) from running. However, Vercel released a change[1] which caused said errors to begin propagating if the API route is running on Vercel. (Technically, it's if the server is running in minimal mode, but all API handlers on vercel do.) A side effect of this change is that when there's an error, `res.end()` is no longer called. As a result, the SDK's work is cut short, and neither errors in API route handlers nor transactions tracing such routes make it to Sentry. This fixes that, by moving the work of finishing the transaction and flushing events into its own function and calling it not only in `res.end()` but also before we rethrow the error. (Note: In the cases where there is an error and the server is not running in minimal mode, this means that function will be hit twice, but that's okay, since the second time around it will just no-op, since `transaction.finish()` bails immediately if the transaction is already finished, and `flush()` returns immediately if there's nothing to flush.) H/t to @jmurty for his work in #4044, which helped me fix some problems in my first approach to solving this problem. Fixes #3917. [1] vercel/next.js#26875
|
Any update? I have the same issue 😭 |
|
I gave up on sentry for my NextJs Vercel setup and just manually pipe all my errors into a database |
|
Not using import * as Sentry from '@sentry/nextjs';
const api: NextApiHandler = async (req, res) => {
try {
// logic here
} catch (error) {
Sentry.captureException(error);
res.status(500).end();
}
}; |
|
I’m the original reporter of this issue. It was fixed for me in prior versions of the Sentry NextJS integration, but may have been broken again in more versions – I’m not sure, we mostly run our important apps self-hosted instead of on Vercel. The new auto-wrap feature seems problematic according to the compatibility matrix in this issue: #6120 |
|
I also have the issue. Does anyone know how to solve this? Here us my sentry configuration for the cloud functions: https://github.com/langfuse/langfuse/blob/main/sentry.server.config.ts |
|
Having the same issue. |
|
@lobsterkatie any update on this? |
|
I'm running into this issue with Specifically, I'm throwing an unhandled error in a NextJS app router endpoint ( |
|
Same issue (as in app router api handlers not being reported in Sentry) with the latest @sentry/nextjs (8.42.0). Locking the version to |
|
reported here #14780 |
Package + Version
@sentry/nextjsVersion:
Description
I was unable to get error reporting from API endpoints deployed in Vercel (as serverless functions) with
@sentry/nextjsversion 6.11.0 but downgrading to 6.4.1 fixed in.Our app is a new one built with Next.js 11.1 from
create-next-appas of last week.We used the latest
@sentry/nextjsconfigured according to the documentation, and with additional changes following the with-sentry example: specifically, added _error.js page anderrpass through to<Component/>in _app.js.Before downgrading, client errors were logged fine but I couldn't get error reports from Vercel serverless functions at all.
Both client- and server-side errors were logged successfully to Sentry when running the project locally with
yarn dev.This is the failing API endpoint I used to test in file pages/api/boom.js:
The problem seems similar to other reported issues:
The text was updated successfully, but these errors were encountered: