feat(nextjs): Auto-wrap API routes #5778

lobsterkatie · 2022-09-20T08:17:17Z

As part of #5505, this applies to API route handlers the same kind of auto-wrapping we've done with the data fetchers (withServerSideProps and the like). Though the general idea is the same, the one extra complicating factor here is that there's a good chance the handlers get to us already wrapped in withSentry, which we've up until now been telling users to use as a manual wrapper. This is handled by making withSentry idempotent - if it detects that it's already been run on the current request, it simply acts as a pass-through to the function it wraps.

Notes:

A new template has been created to act as a proxy module for API routes, but the proxying work itself is done by the same proxyLoader as before - it just loads one template or the other depending on an individual page's path.
Doing this auto-wrapping gives us a chance to do one thing manual withSentry wrapping isn't able to do, which is set the route config to use an external resolver, which will prevent next's dev server from throwing warnings about API routes not sending responses. (In other words, it should solve [@sentry/nextjs] Errored API routes trigger "API resolved without sending a response" #3852.)

lforst

This PR is so satisfying. I have minor remarks and a small requested change that's supposed to reduce potential flakiness.

packages/nextjs/src/utils/withSentry.ts

packages/nextjs/test/integration/test/server/tracingWithSentryAPI.js

lforst · 2022-09-21T10:12:09Z

packages/nextjs/src/config/wrappers/withSentryAPI.ts

+  // In the case where the exported handler is already of the form `withSentry(origHandler)`, `maybeWrappedHandler` is
+  // the wrapped handler returned by `withSentry`, which now has the parameterized route as a property on itself. By
+  // default in JS, functions have `global` as their `this` value, so to be able to get at the route value, we need to
+  // make sure it's called with itself as `this`. Since ultimately we need to give nextjs something *it* will call (and
+  // it won't set the `this` value we want when it does), this means one more wrapper.
+  const newWrapper: WrappedNextApiHandler = (req, res) => {
+    // Make `maybeyWrappedHandler` its own `this`
+    return maybeWrappedHandler.call(maybeWrappedHandler, req, res);
+  };


I don't believe this is necessary since we also turned the function returned from withSentry from an arrow function into an actual function.

To confirm this, I changed this block to return maybeWrappedHandler; and quickly ran the integration tests you wrote, and they all seem to pass.

Am I missing something?

Huh. My first step was going from arrow to regular function, for exactly this reason, but when I logged this inside of the wrapped handler in withSentry, it gave me global. It wasn't until I used call that logging this gave me the wrapped handler.

Lemme try it again to be sure.

UPDATE: Man, was that a whole lot of debugging for an answer that turned out to be extremely simple. I ran my logging-of-this test again, and it confirmed what I found before - without newWrapper, the this value is global, not the wrapped handler. But I also found what you found, which is that the integration tests still passed. Way longer than I'd care to admit later, and after a whole bunch of poking at the integration tests, it finally dawned on me that the current parameterization method is still there as a fallback even after this change.

To test it out, I got rid of newWrapper as you did, and then separately tried both commenting out the fallback and changing the value of wrappedDynamicURL in the test from /api/withSentryAPI/wrapped/dog to /api/withSentryAPI/wrapped/wrapped. In the first case, the transaction name in the wrappedDynamicURL test doesn't get parameterized at all. In the second case, the fallback computes a transaction name of GET /api/withSentryAPI/[animal]/wrapped rather than the correct GET /api/withSentryAPI/wrapped/[animal]. Either way, the tests fail. Put newWrapper back, though, and both scenarios pass.

Ok got it. I am still confused as to how this works and I'll probably never get it. Always, when I think I have it, some thing comes up that completely nukes the concept I have of this.

Anyways, I somehow still don't like our current implementation for the following reasons:

Messing with this/call/bind is always a bit funky - also from a user perspective. Are we sure we're not stomping on user-provided this values?

If the user wraps the API route with some other wrapper (e.g. export dfault myWrapper(withSentry(handler))) we double wrap the handler.

I then thought about doing the following which seems more or less bulletproof: We wrap the handler in any case with withSentryAPI, but we make withSentry idempotent by writing a flag to req when the request was handled by a withSentry wrapper, and bail in the beginning of withSentry when we see that req already has that flag. Wdyt?

(Just realized that that way we lose the way of passing the route name to with sentry, but we can also do that via the req object.)

Messing with this/call/bind is always a bit funky - also from a user perspective. Are we sure we're not stomping on user-provided this values?

With all due respect, I don't agree. Call, apply, and bind are perfectly respectable parts of the language and we use them as intended, all over the SDK. I will grant you that they're not used as commonly as some other language features, but that's exactly why I'm not especially worried about users having set their own this (generally, and especially in this particular situation, where there's nothing that lends itself to this-ing).

If the user wraps the API route with some other wrapper (e.g. export dfault myWrapper(withSentry(handler))) we double wrap the handler.

This, however, is a good point. We (should, if we don't already) tell people to have us be on the outside, but I know as well as anyone from my time doing support that users don't always take our advice.

I then thought about doing the following which seems more or less bulletproof: We wrap the handler in any case with withSentryAPI, but we make withSentry idempotent by writing a flag to req when the request was handled by a withSentry wrapper, and bail in the beginning of withSentry when we see that req already has that flag. Wdyt?

I think I wish we'd had this conversation before I spent hours in Higher Order Function Brain Melt City, but that's no one's fault but the time difference. I think it's a good solution to your second point, which I've now implemented.

Call, apply, and bind are perfectly respectable parts of the language and we use them as intended

Agree, but imo they are by far the most common source of confusion in our code base. So if we can, I would avoid them if possible. (I am aware that in many circumstances they are necessary - in these situations, they are fine ofc)

packages/nextjs/test/integration/test/server/tracingWithSentryAPI.js

lforst · 2022-09-23T10:52:33Z

packages/nextjs/src/config/wrappers/withSentryAPI.ts

+    nextLogger.info(
+      `${_sentryNextjs_} is running with the ${_autoWrapOption_} flag set, which means API routes no longer need to ` +
+        `be manually wrapped with ${_withSentry_}. Detected manual wrapping in ${_route_}.`,
+    );
+  }


I am on the fence about whether I find this message useful or unnecessary. Can't hurt I guess, so it's definitely not blocking (or worth a discussion at this point in time).

My thinking is that eventually, we'll deprecate withSentry, and in the meantime, it's a good way to let people know about the change. Will leave it in for now so as to get this merged, but am open to it not staying there forever.

(Bonus of eventually removing it: We can then merge withSentryAPI and withSentry into one.)

vladanpaunovic

Left a few comments here.

Overall, I think that there are too many comments in this PR making the code harder to read.

vladanpaunovic · 2022-09-23T13:35:28Z

packages/nextjs/src/config/wrappers/withSentryAPI.ts

+      parameterizedRoute,
+    ].map(phrase => formatAsCode(phrase));
+
+    nextLogger.info(


I find this message as a good line in our CHANGELOG.md.

As a user, I would find it annoying to see this message. I don't care if the route is wrapped by Sentry automatically or by me. All I care is that it works.

vladanpaunovic · 2022-09-23T13:37:39Z

packages/nextjs/src/utils/nextLogger.ts

@@ -0,0 +1,31 @@
+/* eslint-disable no-console */
+import * as chalk from 'chalk';


What is the purpose of this logger?

Yes, I checked the implementation on the nextjs repo that you referenced and I don't udnerstand the "why" behind it. :)

Also, I believe that the comment attached is more appropriate as a GH comment then part of the codebase

vladanpaunovic · 2022-09-23T13:40:42Z

packages/nextjs/src/config/loaders/proxyLoader.ts

@@ -47,7 +41,10 @@ export default async function proxyLoader(this: LoaderThis<LoaderOptions>, userC
    return userCode;
  }

-  const templatePath = path.resolve(__dirname, '../templates/proxyLoaderTemplate.js');
+  const templateFile = parameterizedRoute.startsWith('/api')


do we have access to API_ROUTE from next.js?

If so, I would recommend us using that instead when referring to /api folder

We don't - it's not exported - but it's the just the regex version of this same check. Is your concern that they might change the value? (Feels like that'd be a pretty big breaking change on their part...)

vladanpaunovic · 2022-09-23T13:49:02Z

packages/nextjs/test/integration/pages/api/withSentryAPI/unwrapped/noParams.ts

@@ -0,0 +1,7 @@
+import { NextApiRequest, NextApiResponse } from 'next';


I recommend we make a test checking for nested routes like [...all].ts

Docs https://nextjs.org/docs/routing/introduction#dynamic-route-segments

daniellin215 · 2022-10-01T15:50:48Z

So we don't need to manually wrap routes anymore for next.js? This isn't updated/reflected in the documentation.
https://docs.sentry.io/platforms/javascript/guides/nextjs/

lforst · 2022-10-01T16:41:01Z

@daniellin215 This feature is currently sort of in an experimental state and we only really want newly onboarding users to have it - hence no mentioning of this in the docs. People currently have to either manually set the autoInstrumentServerFunctions option or install the SDK via @sentry/wizard to get this feature.

We plan to make the auto wrapping the default in the coming week and with that, we will also update the documentation. The docs will probably not mention withSentry in the default setup guide anymore since the wrapping is done automatically anyways.

youssefm · 2023-03-11T21:55:18Z

@lobsterkatie @lforst it sounds like you guys went to really great lengths to try to wrap everything that NextJS does. It's pretty crazy to have to write a custom webpack loader that renders a template to call specific wrapper code just to do something that's pretty basic in other frameworks with middleware.

Did you all try to talk to the NextJS team to see if they could provide a simpler, first-class way to handle NextJS errors?

lforst · 2023-03-13T12:09:27Z

@youssefm Yeah the logic in our Next.js SDK is a bit hacky. It had its hiccups at first but now it is pretty stable. Unfortunately, we had to go that route because Next.js doesn't provide a "neat" way of doing things. I think you are correct that stuff like this is quite basic in other frameworks.

We are in direct communication with Vercel but getting in changes from our side is not very easy at times and it also always takes ages. It seems like the Next.js team at Vercel has a pretty clear vision of how things should be and they don't want to steer away from it too much.

youssefm · 2023-03-14T01:51:22Z

Thanks for the context @lforst. And nicely done finding a workaround for Next.js' limitations.

I'm finding myself trying to do something similar (wrapping all the API routes with custom code) and it's cool to see Sentry found a way to do so, despite how involved the solution is.

silent1mezzo mentioned this pull request Sep 20, 2022

NextJS doesn't wrap API routes so DB Spans are only attached to root transaction #5779

Closed

3 tasks

lobsterkatie mentioned this pull request Sep 20, 2022

Improve Nextjs tracing #5505

Closed

43 tasks

lobsterkatie force-pushed the kmclb-nextjs-wrap-api-routes branch from b72c950 to 08d4c47 Compare September 21, 2022 04:46

lobsterkatie changed the base branch from master to kmclb-nextjs-add-sampling-context-in-data-fetcher-wapper September 21, 2022 05:45

lobsterkatie force-pushed the kmclb-nextjs-wrap-api-routes branch from 08d4c47 to f9bcb68 Compare September 21, 2022 06:07

lforst reviewed Sep 21, 2022

View reviewed changes

lobsterkatie force-pushed the kmclb-nextjs-add-sampling-context-in-data-fetcher-wapper branch from ab6d376 to 050c525 Compare September 21, 2022 14:01

Base automatically changed from kmclb-nextjs-add-sampling-context-in-data-fetcher-wapper to master September 21, 2022 14:24

lobsterkatie force-pushed the kmclb-nextjs-wrap-api-routes branch 4 times, most recently from f7f8dbd to e1dbf7c Compare September 23, 2022 07:44

lforst approved these changes Sep 23, 2022

View reviewed changes

vladanpaunovic reviewed Sep 23, 2022

View reviewed changes

lobsterkatie added 10 commits September 23, 2022 13:07

make proxy loader handle API routes

100edb7

add API proxy module template

fd3f109

s/proxyLoaderTemplate/pageProxyLoaderTemplate

bdafcab

add nextLogger

fd3d544

allow withSentry to take a parameterizedRoute parameter

8faeba6

add wrapper for API routes

e11aed4

make withSentry's returned wrapper idempotent

4902789

use parameterized route in withSentry, if available

b615b32

convert wrapped handler to named function in withSentry

72704e0

add integration tests

8ed7ea5

lobsterkatie force-pushed the kmclb-nextjs-wrap-api-routes branch from e1dbf7c to 8ed7ea5 Compare September 23, 2022 20:07

lobsterkatie marked this pull request as ready for review September 26, 2022 04:11

lobsterkatie merged commit 1d8370e into master Sep 26, 2022

lobsterkatie deleted the kmclb-nextjs-wrap-api-routes branch September 26, 2022 04:12

vladanpaunovic mentioned this pull request Oct 5, 2022

Remove withSentry in sentry-nextjs package #5893

Closed

IGassmann mentioned this pull request Oct 6, 2022

Plugin breaks Sentry blitz-js/next-superjson-plugin#35

Closed

1 task

onurtemizkan mentioned this pull request Oct 27, 2022

fix(nextjs): Log false positive warning only if request is unfinished. #6070

Merged

AbhiPrasad mentioned this pull request Oct 28, 2022

[@sentry/nextjs] Errored API routes trigger "API resolved without sending a response" #3852

Closed

5 tasks

connor-baer mentioned this pull request Jan 17, 2023

@sentry/next.js 7.31 autoinstrumentation breaks middleware with named export #6815

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat(nextjs): Auto-wrap API routes #5778

feat(nextjs): Auto-wrap API routes #5778

lobsterkatie commented Sep 20, 2022 •

edited

lforst left a comment

lforst Sep 21, 2022

lobsterkatie Sep 21, 2022 •

edited

lforst Sep 22, 2022 •

edited

lobsterkatie Sep 23, 2022

lforst Sep 23, 2022

lforst Sep 23, 2022

lobsterkatie Sep 23, 2022

vladanpaunovic left a comment

vladanpaunovic Sep 23, 2022

vladanpaunovic Sep 23, 2022

vladanpaunovic Sep 23, 2022

lobsterkatie Sep 23, 2022

vladanpaunovic Sep 23, 2022

lobsterkatie Sep 23, 2022

daniellin215 commented Oct 1, 2022

lforst commented Oct 1, 2022

youssefm commented Mar 11, 2023 •

edited

lforst commented Mar 13, 2023

youssefm commented Mar 14, 2023

		@@ -0,0 +1,31 @@
		/* eslint-disable no-console */
		import * as chalk from 'chalk';

		@@ -0,0 +1,7 @@
		import { NextApiRequest, NextApiResponse } from 'next';

feat(nextjs): Auto-wrap API routes #5778

feat(nextjs): Auto-wrap API routes #5778

Conversation

lobsterkatie commented Sep 20, 2022 • edited

lforst left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lobsterkatie Sep 21, 2022 • edited

Choose a reason for hiding this comment

lforst Sep 22, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vladanpaunovic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

daniellin215 commented Oct 1, 2022

lforst commented Oct 1, 2022

youssefm commented Mar 11, 2023 • edited

lforst commented Mar 13, 2023

youssefm commented Mar 14, 2023

lobsterkatie commented Sep 20, 2022 •

edited

lobsterkatie Sep 21, 2022 •

edited

lforst Sep 22, 2022 •

edited

youssefm commented Mar 11, 2023 •

edited