Unable to use Sentry NextJS integration with middleware on Cloudflare Pages

[blitss]

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?

Self-hosted/on-premise

Which SDK are you using?

@sentry/nextjs

SDK Version

7.66.0

Framework Version

7.66.0

Link to Sentry event

No response

SDK Setup

No response

Steps to Reproduce

Hi,
Probably this is not much of a Sentry issue, but popping this here in case you know any workaround for this, or maybe this can be fixed on your side.

Cloudflare workers runtime (not sure if any other serverless runtimes do though) has an issue with running Sentry Next.js integration along with middleware in a project. As the dev of next-on-pages said, the issue here is that Sentry causes "the generation of a randomUUID at the top level of the middleware function file."

Issue on next-on-pages with explanation: cloudflare/next-on-pages#420 (comment)

So maybe Sentry can avoid calling randomUUID at the top level? I don't have much insight into Sentry internals or how Next.js integration works, or even why this doesn't work with middleware specifically but maybe you can shed some light on how this can be resolved.

Repro (repo: Enalmada/next-apps-for-testing#1):

1. Create a NextJS app project and initialize Sentry
2. Create a middleware file and deploy using next-on-pages:

import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
 
export function middleware(request: NextRequest) {
  return NextResponse.next();
}

To run a Next.js project in Cloudflare worker env, you can do so locally:

npx @cloudflare/next-on-pages@1 
npx wrangler pages dev .vercel/output/static

Expected Result

Project works

Actual Result

A promise rejection was handled asynchronously. This warning occurs when attaching a catch handler to a promise after it rejected. (rejection #1)
Error: Some functionality, such as asynchronous I/O, timeouts, and generating random values, can only be performed while handling a request.
    at W (__next-on-pages-dist__/functions/src/middleware.func.js:9:28306)
    at Wt (__next-on-pages-dist__/functions/src/middleware.func.js:9:39049)
    at new se (__next-on-pages-dist__/functions/src/middleware.func.js:9:33435)
    at new ct (__next-on-pages-dist__/functions/src/middleware.func.js:9:39120)
    at Kt (__next-on-pages-dist__/functions/src/middleware.func.js:9:42593)
    at J (__next-on-pages-dist__/functions/src/middleware.func.js:9:42523)
    at Fr (__next-on-pages-dist__/functions/src/middleware.func.js:9:43898)
    at wi (__next-on-pages-dist__/functions/src/middleware.func.js:13:21539)
    at 7819 (__next-on-pages-dist__/functions/src/middleware.func.js:13:22028)
    at _ (__next-on-pages-dist__/functions/src/middleware.func.js:1:729) {
  stack: Error: Some functionality, such as asynchronous I/…es-dist__/functions/src/middleware.func.js:1:729),
  message: Some functionality, such as asynchronous I/O, time…, can only be performed while handling a request.
}

[lforst]

Ok this is a bit hairy. All of our SDKs rely on some randomness mechanism to generate IDs for any events (errors, transactions, replays, profiles, ...). This is really at the core of the SDK and I don't think there currently is a way around this.

But this sucks. I currently don't know what to do about this. I'll bring it to the team.

[lforst]

We probably need to change uuidv4() to return undefined in runtimes where it is not possible for us to create uuids and then return 000000-0000-..... in all of our captureX() methods.

[blitss]

We probably need to change uuidv4() to return undefined in runtimes where it is not possible for us to create uuids and then return 000000-0000-..... in all of our captureX() methods.

You should note though that runtime still has the possibility to create uuids, just not outside the request context. I've tried to look for how to check the current context, but didn't find any solution for this besides using addEventListener and explicitly setting that. So the only viable solution for you (besides moving UUID generation to the request context) seems to be to wrap the uuid generation in try-catch and return undefined if that fails, or just avoid generating UUIDs at that runtime at all.