feat(nextjs): Add edge route and middleware wrappers#6771
Conversation
size-limit report 📦
|
|
|
||
| span?.setStatus('internal_error'); | ||
|
|
||
| captureException(objectifiedErr); |
There was a problem hiding this comment.
l: passing in the event processor above through capture context might help if we have scope bleeding issues
| /** | ||
| * Wraps a Next.js edge route handler with Sentry error and performance instrumentation. | ||
| */ | ||
| export function withSentryAPI<H extends EdgeRouteHandler>( |
There was a problem hiding this comment.
l: Could we get some unit tests for this logic? In particular for the dynamic nature of spanLabel and spanOp
| // We cannot make any assumptions about what users define as their handler except maybe that it is a function | ||
| export interface EdgeRouteHandler { | ||
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| (req: any): any | Promise<any>; |
There was a problem hiding this comment.
l: Should we use unknown?
There was a problem hiding this comment.
Unfortunately, we have to go with any here because making it unknown would cause TS errors when people pass in their original functions into the wrappers.
| */ | ||
| export function withEdgeWrapping<H extends EdgeRouteHandler>( | ||
| handler: H, | ||
| options: { spanLabel: string; spanOp: string; mechanismFunctionName: string }, |
There was a problem hiding this comment.
m: why don't we use spanDescription instead of spanLabel here? I think we should keep the span option naming consistent.
Though spans having descriptions and transactions having names is still something I feel we gotta fix somehow.
applies to the other uses as well
Ref #6120
Ref #4206
This PR adds two wrappers,
withSentryAPIandwithSentryMiddleware, to the mini Edge Runtime SDK for Next.js that allow users to wrap their Edge routes and middleware with error and performance instrumentation.